Skip to content

feat(about): name the running build on /about and /api/health - #224

Merged
ABB65 merged 1 commit into
mainfrom
feat/about-version
Sep 2, 2026
Merged

feat(about): name the running build on /about and /api/health#224
ABB65 merged 1 commit into
mainfrom
feat/about-version

Conversation

@ABB65

@ABB65 ABB65 commented Sep 1, 2026

Copy link
Copy Markdown
Member

Summary

Closes #206.

/about reported profile, edition and billing but not the version, and /api/health returned only { status, timestamp }. An operator could not tell which build a deployment was running from inside the product — the first thing the bug template asks for.

  • Build stamp. nuxt.config.ts puts { version, commit } into runtimeConfig.public.build at build time. Version is package.json; commit is resolved from SOURCE_COMMITRAILWAY_GIT_COMMIT_SHAGITHUB_SHACI_COMMIT_SHAVERCEL_GIT_COMMIT_SHAgit rev-parse HEAD, in that order, and is empty when nothing knows. Both are overridable at run time (NUXT_PUBLIC_BUILD_VERSION / NUXT_PUBLIC_BUILD_COMMIT).
  • /about. A Version row at the top of the Deployment block: v0.3.0 (1a2b3c4), v0.3.0 without a commit, unknown without either (shared/utils/build-info.ts).
  • /api/health. Now { status, timestamp, version, commit } so uptime checks can assert on the deployed build.
  • Dockerfile. .git is not in the build context, so the build stage takes ARG SOURCE_COMMIT / ARG RAILWAY_GIT_COMMIT_SHA. The release workflow passes SOURCE_COMMIT for the GHCR images; Railway supplies its own variable to the build automatically.
  • Docs: DOCKER.md (build arg + health payload), DEPLOYMENT.md smoke checks.

Test plan

  • tests/unit/build-info.test.ts — formatting rules (tag+sha, tag only, sha only, unknown)
  • tests/integration/system-workspace-routes.integration.test.ts — health payload carries version/commit, and still answers without a build stamp
  • lint + nuxt typecheck
  • Staging after merge: /about shows v0.3.0 (<sha of main>) and curl /api/health returns the same sha (Railway build — confirms RAILWAY_GIT_COMMIT_SHA reaches the build stage)

🤖 Generated with Claude Code

https://claude.ai/code/session_01Chid3TnLdPHjsKip4n63Ky

An operator looking at a deployment could not answer "which build is
this?" from the product: /about described profile, edition and billing
but not the version, and /api/health said only `ok`. The bug report
template's first required field is the Studio version, and after a
release the only way to know whether staging was serving it was to
exercise the fixed behaviour or ask whoever deployed.

The version and commit are now stamped at build time into
`runtimeConfig.public.build` (package.json version + the commit the
build was made from) and shown on /about as `v0.3.0 (1a2b3c4)`. The
commit is also returned by /api/health so an uptime check can assert a
deploy landed. `.git` is outside the Docker build context, so the
Dockerfile takes it as `SOURCE_COMMIT` (passed by the release workflow)
or `RAILWAY_GIT_COMMIT_SHA` (exported by Railway builds); a build that
knows neither shows the version alone rather than an invented sha.

Closes #206
@ABB65
ABB65 merged commit db627dc into main Sep 2, 2026
2 checks passed
@ABB65
ABB65 deleted the feat/about-version branch September 2, 2026 09:06
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.

About this deployment does not show the running version

1 participant