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. Version, commit and build date are now compiled in, defaulting to dev/unknown so a plain `go build` still works, and surfaced two ways: --version prints and exits startup log structured, via setupLog, before the manager is constructed Note the stdlib runtime package is imported as goruntime here: the k8s apimachinery runtime is already imported under that name. debug.ReadBuildInfo() is not a substitute: it reports "(devel)" for a build not driven by `go install module@version`, which is the case for the container build. The workflow passes VERSION from docker/metadata-action rather than reconstructing it, so the image tag and the reported version cannot drift. A metric label was considered and deliberately left out for now — it would mean registering a custom collector, and the startup log plus the aggregated /platform/version endpoint in the api cover the immediate need.
flaccid
added
enhancement
golangci-lint failed with: cmd/main.go:24:1: File is not properly formatted (goimports) goimports wants a blank line before a comment-led import within a group. gofmt accepts it either way, which is why this passed locally — the repo lints with goimports, not plain gofmt. Verified with goimports -l and golangci-lint run (0 issues).
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)Defaults are
dev/unknown, so a plaingo buildstill works.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
`runtime` is already imported under that name