feat: report the build version at runtime; add release automation - #3
Merged
Conversation
Part of kube-workspaces/deploy#2. Adds a release workflow and the .github/release.yml categories used to generate notes, both identical across the five repositories so a reader moving between them sees the same structure. The note preamble comes from a shared generator in the deploy repo, which classifies the commits since the last tag. That matters here because this component often has nothing but CI and docs changes in a cycle and still gets tagged to hold the platform version line — in that case the notes say so explicitly rather than leaving someone to infer it from a list of CI commits. The workflow defaults to a dry run so the notes can be reviewed before anything is tagged.
Closes #2. Nothing recorded which version was running. The Dockerfile built with no -ldflags, there was no version variable, and no endpoint reported one — so the only signal was the image tag, which is `latest` in the default manifests and therefore says nothing. Reproducing a bug report meant guessing the build. Version, commit and build date are now compiled in, defaulting to dev/unknown so a plain `go build` still works, and surfaced three ways: --version prints and exits startup log so a pod is identifiable from its logs alone GET /version JSON, including Go version and platform `/healthz` and `/readyz` also gain a version field. The existing "status" field stays first and unchanged — the container probes and the deployment smoke tests both match on it. Note debug.ReadBuildInfo() is not a substitute: it reports "(devel)" for a build that is not driven by `go install module@version`, which is the case here. The workflow passes VERSION from docker/metadata-action rather than reconstructing it, so the image tag and the reported version cannot drift. Verified end to end: a real docker build with --build-arg produces a binary reporting "v0.3.0-test (commit deadbeef, ...)", and deployed to kind the endpoints serve it while the smoke suite still passes 35/35.
flaccid
added
enhancement
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2. Part of kube-workspaces/deploy#2.
Version at runtime
Nothing recorded which version was running. The Dockerfile built with no
-ldflags, there was no version variable, and no endpoint reported one — so theonly signal was the image tag, which is
latestin the default manifests andtherefore says nothing. Reproducing a bug report meant guessing the build.
Version, commit and build date are now compiled in and surfaced:
--versionv0.3.0 (commit abc1234, built …, linux/amd64, go1.26.7)GET /version/healthz,/readyzversionfieldDefaults are
dev/unknown, so a plaingo buildstill works.The existing
"status"field in the health responses stays first and unchanged— the container probes and the deployment smoke tests both match on it.
The workflow passes
VERSIONfromdocker/metadata-actionrather thanreconstructing it, so the image tag and the reported version cannot drift.
Release automation
Adds the release workflow and
.github/release.ymlcategories, identical acrossthe five repositories. The note preamble comes from a shared generator in the
deploy repo which states explicitly when a release has no functional changes —
relevant here, since a component is often tagged only to hold the platform
version line.
The workflow defaults to a dry run so notes can be reviewed before tagging.
Verification
`v0.3.0-test (commit deadbeef, …)`
deployment smoke suite still passes 35/35