Skip to content

build: stamp the version into the published Docker images - #33

Merged
jravani merged 1 commit into
mainfrom
chore/stamp-version-into-docker-images
Sep 5, 2026
Merged

jravani merged 1 commit into
mainfrom
chore/stamp-version-into-docker-images

Conversation

@jravani

@jravani jravani commented Sep 5, 2026

Copy link
Copy Markdown
Member

Problem

ignis -version inside ghcr.io/thd-spatial-ai/ignis reports dev (commit none, built unknown). The image build (environment/ignis-app.dockerfile) never passed the -ldflags -X that release.yml uses for the standalone binaries, so a running container cannot report which release it is. Confirmed on the just-deployed 0.5.0.

Change

  • Both environment/*.dockerfile take VERSION, COMMIT, DATE build args and pass them to go build as -ldflags -X, matching release.yml. Defaults are the same values internal/version hard-codes, so a plain docker build and the docker-compose.yml dev path are unchanged.
  • docker-publish.yml supplies the args: VERSION from metadata-action's {{version}} (the image tag, e.g. 0.5.0 — note this omits the leading v, consistent with the published tags), COMMIT from github.sha, DATE from a build-step timestamp.
  • The version-line format moves from cmd/ignis into version.String(), so build_db prints it in its startup banner too. The format test moves to internal/version with it.

Verification (local)

Build ignis -version / build_db banner
--build-arg VERSION=0.5.0 … 0.5.0 (commit c2f8e2f…, built 2026-09-05T…)
no build args (dev path) dev (commit none, built unknown)

go build ./..., go vet ./..., go test ./... pass.

Note

This takes effect on the next tag. To stamp the already-published 0.5.0 images, re-run the Publish Docker images workflow via workflow_dispatch on the tag after merge.

https://claude.ai/code/session_01JBfY6ZG2W52imgy2M1JGYo

`ignis -version` in the ghcr.io/thd-spatial-ai/ignis image reported
"dev (commit none, built unknown)" because the image build never passed
the -ldflags -X that release.yml uses for the standalone binaries. A
deployed container could not say which release it was running.

- Both environment/*.dockerfile take VERSION, COMMIT and DATE build args
  (defaulting to the same values internal/version hard-codes, so a plain
  `docker build` and the dev compose path are unchanged) and pass them
  to `go build` as -ldflags -X, matching release.yml.
- docker-publish.yml passes those args: VERSION from the image tag
  (metadata-action's {{version}}, e.g. 0.5.0), COMMIT from github.sha,
  DATE from a build-time timestamp.
- The version-line format moves from cmd/ignis into version.String() so
  build_db can print it in its startup banner too; its test moves to
  internal/version with it.

Verified locally: a stamped app image reports the real version, a
stamped build_db logs it in its banner, an unstamped build still reports
the hard-coded defaults.

Claude-Session: https://claude.ai/code/session_01JBfY6ZG2W52imgy2M1JGYo
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
cmd/build_db/main.go 0.00% 1 Missing ⚠️
cmd/ignis/main.go 0.00% 1 Missing ⚠️

📢 Thoughts on this report? Let us know!

@jravani
jravani merged commit 6e155e2 into main Sep 5, 2026
6 checks passed
@jravani
jravani deleted the chore/stamp-version-into-docker-images branch September 5, 2026 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants