UN-2265 [FEAT] Show the running platform version on the profile page#2034
UN-2265 [FEAT] Show the running platform version on the profile page#2034athul-rs wants to merge 2 commits into
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
WalkthroughBuild-time VERSION is added to the frontend Dockerfile, exposed as UNSTRACT_APPS_VERSION, escaped and injected into runtime-config.js as window.RUNTIME_CONFIG.version, surfaced in frontend/src/config.js, and conditionally shown in the profile UI as "Platform Version". ChangesPlatform Version Display
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|---|---|
| docker/dockerfiles/frontend.Dockerfile | Adds ARG VERSION="" and ENV UNSTRACT_APPS_VERSION=${VERSION} at the end of the production stage; empty default correctly hides the version field when no build arg is supplied. |
| frontend/generate-runtime-config.sh | Adds js_escape() to sanitize backslashes and double quotes before embedding the version string in the JS object literal; pre-computes APP_VERSION to avoid heredoc re-expansion issues. |
| frontend/src/config.js | Adds version: runtimeConfig.version |
| frontend/src/components/profile/Profile.jsx | Conditionally renders a Platform Version field in the Organization card using existing field-group styling; guarded by config.version && so the field is invisible when no version is available. |
Sequence Diagram
sequenceDiagram
participant CI as CI / Docker Build
participant DF as frontend.Dockerfile
participant SH as generate-runtime-config.sh
participant RC as window.RUNTIME_CONFIG
participant CF as config.js
participant UI as Profile.jsx
CI->>DF: "--build-arg VERSION=v0.144.0"
DF->>DF: "ARG VERSION="" → ENV UNSTRACT_APPS_VERSION"
Note over DF: Empty default hides field when arg is omitted
Note over SH: Container start (nginx entrypoint.d)
SH->>SH: js_escape(UNSTRACT_APPS_VERSION)
SH->>RC: "write runtime-config.js { version: "v0.144.0" }"
UI->>CF: import config
CF->>RC: runtimeConfig.version
RC-->>CF: "v0.144.0" (or "" → VITE_VERSION fallback)
CF-->>UI: config.version
alt config.version is truthy
UI->>UI: render "Platform Version: v0.144.0"
else config.version is falsy
UI->>UI: field hidden (no render)
end
Reviews (2): Last reviewed commit: "UN-2265 Address review: empty VERSION de..." | 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
|
|
||
| # Capture build version at the very end so it doesn't affect layer caching | ||
| ARG VERSION=dev | ||
| ENV UNSTRACT_APPS_VERSION=${VERSION} |
There was a problem hiding this comment.
@athul-rs does this get set during cloud builds as well?
There was a problem hiding this comment.
Yes — cloud frontend builds go through docker bake with *.args.VERSION=${{ inputs.tag }} (cloud-frontend-docker-build-push.yaml), same as OSS production-build.yaml, so cloud images get the rc tag baked in automatically. On-prem frontend builds use the same workflow pattern.
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
Frontend Lint Report (Biome)✅ All checks passed! No linting or formatting issues found. |
|
@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. |
3 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
Version flows build → runtime → UI with no new endpoints:
frontend.Dockerfile(production stage):ARG VERSION=dev→ENV UNSTRACT_APPS_VERSION, added at the end to avoid layer-cache invalidation — the exact patternbackend.Dockerfilealready uses. Production CI already passes*.args.VERSIONto all services via docker bake (production-build.yaml), so published frontend images get the real version with no CI change.generate-runtime-config.sh: 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.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),config.versionis empty and the field simply doesn't render.Database Migrations
Env Config
UNSTRACT_APPS_VERSION(frontend container) — auto-populated from theVERSIONbuild arg; can also be set at runtime (e.g. Helm env) to override.Relevant Docs
Related Issues or PRs
Notes on Testing
sh -npasses on the runtime-config script; pre-commit hadolint passed on the Dockerfile change.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