UN-2265 [FEAT] Show the running platform version on the profile page#2034
Conversation
Bake the build VERSION into the frontend image as UNSTRACT_APPS_VERSION (same pattern as backend.Dockerfile), surface it through the runtime config injected at container start, and show it as a 'Platform Version' field on the profile page. Production CI already passes *.args.VERSION to all images via docker bake, so published images carry the real version on every deployment target; the field is hidden when no version is available (e.g. local npm start). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
athul-rs
requested review from
chandrasekharan-zipstack,
hari-kuriakose and
jaseemjaskp
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Summary by CodeRabbit
WalkthroughAdds a version value from Docker Compose into runtime config, exposes it through frontend config, and shows it in the profile UI when present. ChangesPlatform version exposure
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| Filename | Overview |
|---|---|
| frontend/generate-runtime-config.sh | Adds js_escape helper and APP_VERSION injection; correctly pre-processes the value before the heredoc expansion and falls back to empty string when env var is unset. |
| frontend/src/config.js | Adds version field following the established runtime-config-first, VITE-env-fallback pattern; empty string from the script falls through correctly to undefined when no fallback is set. |
| frontend/src/components/profile/Profile.jsx | Adds conditionally rendered Platform Version field using existing field-group styling; correctly gates on config.version truthiness so the field is hidden when version is absent. |
| docker/docker-compose.yaml | Passes ${VERSION} as UNSTRACT_APPS_VERSION to the frontend service; unset VERSION produces an empty value, which the runtime script handles correctly. |
Sequence Diagram
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Deploy as Deployment (compose / Helm)
participant Script as generate-runtime-config.sh
participant Config as window.RUNTIME_CONFIG
participant JS as config.js
participant UI as Profile.jsx
Deploy->>Script: "UNSTRACT_APPS_VERSION=v0.144.0"
Script->>Script: js_escape(value) → APP_VERSION
Script->>Config: version: "v0.144.0"
Config->>JS: runtimeConfig.version
JS->>UI: "config.version = "v0.144.0""
UI->>UI: "{config.version && Platform Version field rendered}"
Note over Deploy,UI: When UNSTRACT_APPS_VERSION is unset
Deploy->>Script: (empty)
Script->>Config: version: ""
Config->>JS: "" (falsy) → VITE_VERSION fallback → undefined
JS->>UI: "config.version = undefined"
UI->>UI: field hidden
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant Deploy as Deployment (compose / Helm)
participant Script as generate-runtime-config.sh
participant Config as window.RUNTIME_CONFIG
participant JS as config.js
participant UI as Profile.jsx
Deploy->>Script: "UNSTRACT_APPS_VERSION=v0.144.0"
Script->>Script: js_escape(value) → APP_VERSION
Script->>Config: version: "v0.144.0"
Config->>JS: runtimeConfig.version
JS->>UI: "config.version = "v0.144.0""
UI->>UI: "{config.version && Platform Version field rendered}"
Note over Deploy,UI: When UNSTRACT_APPS_VERSION is unset
Deploy->>Script: (empty)
Script->>Config: version: ""
Config->>JS: "" (falsy) → VITE_VERSION fallback → undefined
JS->>UI: "config.version = undefined"
UI->>UI: field hidden
Reviews (5): Last reviewed commit: "Merge branch 'main' into UN-2265-fronten..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/generate-runtime-config.sh`:
- Line 13: The runtime-config write interpolates UNSTRACT_APPS_VERSION directly
into a JS string (version: "${UNSTRACT_APPS_VERSION:-}"), which can break the
resulting runtime-config.js if the env contains " or \; sanitize/escape the
value before writing. Replace occurrences of backslash and double-quote (and
newlines) in UNSTRACT_APPS_VERSION with escaped sequences (e.g. \ -> \\ and " ->
\") or produce a safe JS string using a JSON-stringifier (jq -R . or similar)
and then insert that quoted/escaped output into the version field so
runtime-config.js remains valid; update the portion of
generate-runtime-config.sh that emits the version line to use the
escaped/JSON-encoded value instead of the raw variable.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6d3b8725-fafd-4dd7-992a-783b76071583
📒 Files selected for processing (4)
docker/dockerfiles/frontend.Dockerfilefrontend/generate-runtime-config.shfrontend/src/components/profile/Profile.jsxfrontend/src/config.js
jaseemjaskp
left a comment
jaseemjaskp
left a comment
There was a problem hiding this comment.
@athul From my point of view, the platform version is not particularly relevant to display in OSS or other environments.
For OSS, users already know which version they have deployed locally. For on-prem deployments, we maintain a version tracker and customers know exactly which version they are running. In cloud deployments, customers are always on the latest version, and we already know what version is currently deployed.
Because of that, I don’t think customers need to be aware of the platform version. I also don’t recall many enterprise applications exposing the platform version prominently in the UI.
|
@jaseemjaskp I think its useful to display the version for several reasons and we don't lose anything on attempting to do so. Its more of a convenience here
Do you see any engineering challenges or concerns in displaying this? |
…e config - ARG VERSION defaults to empty so images built without a version hide the field instead of showing 'dev' - Escape backslashes/quotes before embedding the version in the generated JS
|
@jaseemjaskp fair point — taking this back to the ticket's intent rather than pushing my own view: UN-2265 was filed by @chandrasekharan-zipstack from a suggestion that surfacing the version helps support triage (when a user reports an issue, we can ask what version the UI shows instead of cross-referencing deploy trackers). The OSS docker-compose case is the strongest one IMO: That said, this is a product call, not mine. Options as I see them:
Happy with whichever you and Chandru align on — the change is additive and cheap to drop or gate. |
|
@hari-kuriakose What should be the approach here ? Let's update the PR and ticket in jira accordingly. |
|
@athul-rs We need to show the release version in UI, dynamically pulled from the Docker compose file in OSS and Helm chart in Enterprise. Both OSS platform end users and Enterprise On-prem customer dev teams will not have a clue otherwise. A release version is a vital information when filing or debugging an issue. |
RC->stable promotion re-tags images (it does not rebuild), so a version baked
into the frontend image at build time would stay frozen at the rc tag after
promotion. Drop the frontend.Dockerfile ARG/ENV baking and instead supply
UNSTRACT_APPS_VERSION from docker-compose using ${VERSION} -- the same value
that already tags the image, so the displayed version always matches what runs.
Addresses review from @ritwik-g / @ejhari (version must come dynamically from
compose in OSS and the Helm chart in Enterprise).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ion-display # Conflicts: # frontend/generate-runtime-config.sh
Frontend Lint Report (Biome)✅ All checks passed! No linting or formatting issues found. |
|
5 participants
What
v0.144.0) on all deployment targets — OSS docker, cloud, on-prem.Why
UN-2265 — most apps surface their running version; users reporting issues currently have no way to tell us what version they're on, which slows down troubleshooting.
How
The version is supplied at runtime (never baked into the image) and flows env → runtime config → UI with no new endpoints:
UNSTRACT_APPS_VERSIONis provided by the deployment:docker/docker-compose.yaml):UNSTRACT_APPS_VERSION=${VERSION}on the frontend service — the same${VERSION}that already tags every image, so the shown version always matches what's running.generate-runtime-config.sh: readsUNSTRACT_APPS_VERSION(js-escaped) and injectsversionintowindow.RUNTIME_CONFIGat container start (existing mechanism).config.js: exposesconfig.version(runtime config first,VITE_VERSIONenv fallback for dev).Profile.jsx: renders the field only when a version is available, using the existing field-group styling.Why runtime env and not a build-time bake (revised after review): RC→stable promotion only re-tags images — it does not rebuild them — so a version baked into the image at build time would freeze at the
rctag and be shown in Production. Sourcing from the runtime env (compose for OSS, Helm anchor for Enterprise) keeps the displayed version aligned with the promoted release. (per @ritwik-g / @ejhari)Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)
UNSTRACT_APPS_VERSIONis unset (older images, local dev server, or a deployment that doesn't set it),config.versionis empty and the field simply doesn't render. No image now bakes a version, so nothing is removed that anything else depended on.Database Migrations
Env Config
UNSTRACT_APPS_VERSION(frontend container) — supplied at runtime: docker-compose passes${VERSION}in OSS; Helm injects the chart version anchor in Enterprise/On-prem (Zipstack/unstract-cloud#1621). No longer a build arg.Relevant Docs
Related Issues or PRs
UNSTRACT_APPS_VERSIONinto the frontend container from the Helm chart.Notes on Testing
sh -npasses on the runtime-config script.VERSION=v9.9.9 docker compose configrendersUNSTRACT_APPS_VERSION: v9.9.9on the frontend service; unsetVERSION→ empty → field hidden.UNSTRACT_APPS_VERSION=v1.2.3on the frontend container → profile page showsPlatform Version: v1.2.3; unset → field hidden.Screenshots
N/A
Checklist
I have read and understood the Contribution Guidelines.
🤖 Generated with Claude Code