You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The script in scripts/build/binary sets ldflags to set various version/build info in internal/pkg/build, but this is only used by kwil-cli. The script should also set the values for internal/pkg/version, which is what is used by both kwild and kwil-admin. I don't believe kwild ever reported any version before that update.
Also, the GIT_VERSION shell variable established in scripts/build/binary/.git_variables is mostly obsolete since the VCS info is accessible directly to a go app as done in the new internal/pkg/version. The only point here is the version string, which is possibly a point of contention. I am making a case for setting the semver string ourselves rather than having git report it based on the previous tag, which may not reflect what we want or even be proper semver.
Regarding generation of the binaries we intend to distribute in our new releases/binaries repo, I believe that this should be done ourselves, where we should sign the archives with our PGP key and include the detached signature with the archives. With the release.yaml CI workflow currently disabled, I think we are currently doing the docker pushes manually too.
A related topic is that the old goreleaser file only builds kwil-cli. I know we are using the build scripts mentioned above from our task:build commands instead of this, but the goreleaser build command's functionality (not goreleaser release which also publishes/uploads/etc.) appears to be a sensible tool for generating binaries for multiple platforms and architectures in one go. (cross compiling is a breeze for the Go compiler, at least as long as are not using CGO). I'll see if helps with the multi-arch cross compile, although in the past I have used a small builder app written in Go. If goreleaser works, then it's by far the path of least resistance for us.
The text was updated successfully, but these errors were encountered:
If you have an overall plan then feel free to make changes, the way we handle version and build info is not well planned(most of the code from scripts/build is just simply copied and modified).
The script in
scripts/build/binary
setsldflags
to set various version/build info ininternal/pkg/build
, but this is only used bykwil-cli
. The script should also set the values forinternal/pkg/version
, which is what is used by bothkwild
andkwil-admin
. I don't believekwild
ever reported any version before that update.Also, the
GIT_VERSION
shell variable established inscripts/build/binary/.git_variables
is mostly obsolete since the VCS info is accessible directly to a go app as done in the newinternal/pkg/version
. The only point here is the version string, which is possibly a point of contention. I am making a case for setting the semver string ourselves rather than having git report it based on the previous tag, which may not reflect what we want or even be proper semver.Regarding generation of the binaries we intend to distribute in our new releases/binaries repo, I believe that this should be done ourselves, where we should sign the archives with our PGP key and include the detached signature with the archives. With the release.yaml CI workflow currently disabled, I think we are currently doing the docker pushes manually too.
A related topic is that the old goreleaser file only builds kwil-cli. I know we are using the build scripts mentioned above from our
task:build
commands instead of this, but thegoreleaser build
command's functionality (notgoreleaser release
which also publishes/uploads/etc.) appears to be a sensible tool for generating binaries for multiple platforms and architectures in one go. (cross compiling is a breeze for the Go compiler, at least as long as are not using CGO). I'll see if helps with the multi-arch cross compile, although in the past I have used a small builder app written in Go. If goreleaser works, then it's by far the path of least resistance for us.The text was updated successfully, but these errors were encountered: