Skip to content

build: let a packaged build say which build it is (opt-in APP_BUILD) - #244

Merged
DuarteSantos8 merged 1 commit into
DuarteSantos8:mainfrom
kurktchiev:gh/build-identity
Sep 28, 2026
Merged

DuarteSantos8 merged 1 commit into
DuarteSantos8:mainfrom
kurktchiev:gh/build-identity

Conversation

@kurktchiev

Copy link
Copy Markdown
Contributor

__APP_VERSION__ is read from frontend/package.json, so every image built between two releases reports the same number. From inside the app there is no way to tell one build of 1.3.7 from another — which means the question a bug report turns on, which build were you running?, has no answer, and "I tested it, no change" cannot be told apart from a stale service-worker cache.

That happened to me twice in one day on a self-hosted deployment: two rounds of testing a timer change were unresolvable because the tester's phone reported v1.3.7 either way.

The change

Two lines of substance:

  • frontend/vite.config.js — when process.env.APP_BUILD is set, __APP_VERSION__ becomes `${pkgVersion}+${APP_BUILD}`. Unset, it is exactly pkgVersion, as now.
  • web/Dockerfile — takes ARG APP_BUILD="" in the build stage and passes it to npm run build. (The existing VERSION/VCS_REF args live in the runtime stage, which is after vite has already run, so they cannot reach the bundle.)

Nothing else moves. Settings → About and the footer already render __APP_VERSION__, so a build that sets it reads openGym v1.3.7+2026-09-17.3 and one that does not reads openGym v1.3.7.

Why opt-in rather than always-on

A release build should say 1.3.7 and nothing else — that is the number people are asked for, and 1.3.7+abc1234 in a release would be noise. The suffix is for builds that are not releases: CI artifacts, nightlies, a self-hoster's own image. docker compose up --build without the arg is unchanged, which is the path almost every self-hoster takes.

Suggested use in CI: --build-arg APP_BUILD=$CI_PIPELINE_ID or a date stamp.

Checked

  • npm test in frontend/ — 1468 passing across 100 files
  • npm run build with APP_BUILD=demo.1 → the bundle contains 1.3.7+demo.1
  • npm run build with it unset → the bundle contains no + suffix at all, i.e. the string is byte-identical to today's
  • No new dependency; process.env is already how vite config reads its environment
  • CHANGELOG.md left alone

🤖 Generated with Claude Code

__APP_VERSION__ comes from package.json, so every image built between two
releases calls itself 1.3.7 and the one question a bug report turns on — which
build were you running? — has no answer from inside the app. Twice today a
"I tested it, no change" could not be told apart from a stale cached build.

vite.config.js appends process.env.APP_BUILD as "1.3.7+<build>" when it is set,
and web/Dockerfile takes it as a build-arg in the build stage (the existing
VERSION arg lives in the runtime stage, which is after vite has already run).
Unset — every upstream and self-hoster build — the string is exactly
package.json's version as before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@DuarteSantos8
DuarteSantos8 merged commit f9ea6f3 into DuarteSantos8:main Sep 28, 2026
4 checks passed
DuarteSantos8 added a commit that referenced this pull request Sep 28, 2026
…the app does, so a build that sets APP_BUILD runs them against its own installed version
@DuarteSantos8

Copy link
Copy Markdown
Owner

Thanks @kurktchiev. With APP_BUILD set, Settings shows v1.3.9+<build> and the update check ignores the build part on both sides (the version-compare fix from #250 went in first). Nothing in CI sets it yet, so it stays opt-in.

Released in v1.3.9: https://github.com/DuarteSantos8/openGym/releases/tag/v1.3.9

@kurktchiev
kurktchiev deleted the gh/build-identity branch September 29, 2026 11:46
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