add a Dockerfile and shell script for ... #520
Conversation
CodeSee Review Map:Review in an interactive map View more CodeSee Maps Legend |
Dockerfile.linux-build
Outdated
| # reproducible builds for downstream forks and Ziti contributors | ||
| # | ||
|
|
||
| ARG go_distribution_file=go1.16.9.linux-amd64.tar.gz |
There was a problem hiding this comment.
is there a reason you couldn't pull from a particular go base image? also - ziti updates the version of go aggressively. i think 17 is already required. is it possible to pass this via variable?
There was a problem hiding this comment.
or maybe even use 'latest'? this feels like it could be a bit of a maintenance issue that will get lost. right now i think we rely on it being in the action's file but maybe we need to make this a variable for the project...
There was a problem hiding this comment.
after looking through the rest of the PR i'm wondering if this is this still needed or if it was solved on a different pr?
There was a problem hiding this comment.
It's still needed unless there's already a local reproducible build counterpart to the procedures that GitHub Actions uses to build for Linux. I didn't find one in the local development resources.
I'll send an update to track the version of Go that's actually needed, if possible.
There was a problem hiding this comment.
Also, would /quickstart/local be a better home for these?
There was a problem hiding this comment.
@plorenz Where is the recommended version of Go detectable inside the repo? Is there a ziti-ci command for that? I looked through the ziti-ci and ziti repos but didn't find it.
There was a problem hiding this comment.
You can look at the go.mod file for the ziti project. It has the required major release of go listed go 1.17. So currently the recommended version would be the latest patch version of 1.17.
qrkourier
force-pushed
the
dockerfile-for-linux-builds
branch
2 times, most recently
from
7ecd420
to
37fd6ab
Compare
…l Ziti artifacts to enable forks and contributors who can't run ziti-ci Release v0.22.12 always build the Linux container with latest Go Use go install instead of go get reconcile upstream's main workflow reconcile upstream's common/version/info_generated.go
qrkourier
force-pushed
the
dockerfile-for-linux-builds
branch
from
37fd6ab
to
3ac5d55
Compare
|
@dovholuknf @plorenz I've updated the PR with comments to guide the downstream/fork builder to build with latest Go and where to find the minimum Go requirement for local builds. |
|
@plorenz Will you let me know if you need me to make any changes to this one? This is to add tools for downstream contributors to build artifacts on Linux in the same way that the upstream's Actions workflows do. |
I think the implementation is fine. I wonder how useful it is. If a developer wants to build, aren't they likely to build on their target system? If that's the case all they need to do is |
|
Yes, I think they'll want to build the artifacts for all supported architectures on their workstation, but not necessarily run the artifact on their own workstation e.g. build for ARM on x86_64, run on ARM (just like we do in Actions for the upstream). I'd love to avoid any future burden to maintain this, but I don't see a better way to document and automate the procedure for building for all supported architectures in downstream contributors' environments. My assumptions include that our upstream's Actions workflows will always fail when triggered by downstream repos' merges, and that it's better to offer them an alternative to enabling Actions in their forks than to make their forks' Actions functional. If you like having these tools in the repo, they might be better organized under build tools or quick starts. |
|
Seems reasonable. There should probably be a link to these somewhere in docs |
…reproducible Linux builds of all Ziti artifacts to enable forks and contributors who can't run ziti-ci.