fix(status): show the release version on the admin status page#645
Conversation
Two coupled changes so /ui/admin/status reports the deployed release instead of "1.0.0+no-version-set" / branch "main": - The profiling image (the prod hot-deploy target) is now built only on a tag push or manual dispatch, not on every main-push. Both runs pushed the same :profiling-<sha> tag, so a main-push build could stamp ref=main over the release tag's build (last-writer-wins). Tag/dispatch-only makes the deployed image's APP_BUILD_REF deterministically the release tag. - The Application version field now prefers that baked APP_BUILD_REF (a version tag, e.g. v6.3.4 -> 6.3.4) over Composer's root version, which reads 1.0.0+no-version-set in a CI build with no tag/VCS context. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the version retrieval logic in GetStatusAction. It extracts the environment reading logic into a private helper method buildEnv and introduces a new appVersion method to parse the release version from the APP_BUILD_REF environment variable (stripping the leading 'v' if present), falling back to Composer's root version. Additionally, a new test testVersionPrefersTheBuildRefTag has been added to verify this behavior. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
/ui/admin/statusshowedVersion: 1.0.0+no-version-setandBranch/Tag: mainfor a deployed release, so the running version wasn't legible. Two coupled causes:1.0.0+no-version-setin the Docker build (noCOMPOSER_ROOT_VERSION, no.git).mainbecause the profiling image:profiling-<sha>was built by both the main-push and the tag run — same tag, last writer wins, and main-push won.Changes
:profiling-<sha>always carries its release tag inAPP_BUILD_REF.APP_BUILD_REF(a version tag → stripped of the leadingv) and falls back to Composer's root version otherwise.Verification
GetStatusActionTest::testVersionPrefersTheBuildRefTag— withAPP_BUILD_REF=v9.9.9,app.versionis9.9.9andbuild.refisv9.9.9. Full unit suite + PHPStan L10 + cs-fixer green locally.Note: the
Update-Prüfung fehlgeschlagenline is separate — the client-side check reachesapi.github.comfrom the admin's browser, which the NR network appears to block/rate-limit (the endpoint returns 200 from outside). Not addressed here.Deploy note
After this lands,
:profiling-<sha>is produced by the tag build only; the hot-deploy runbook (deploy:profiling-<main-HEAD-sha>, which equals the tag's commit) is unchanged.