rk@tigase.net opened 1 day ago
-
Suspected Root Causes
Possible causes include:
- Metadata injected only in dev build, not production build
- Build args not passed through Dockerfile correctly
- Multi-stage Docker build not propagating ARG → ENV
- Frontend build using static env file that is not updated
- CI pipeline not injecting correct values
- Docker layer caching retaining stale metadata
npm buildnot receiving runtime environment variables
-
Time Estimate
Task Hours Investigate current injection mechanism 1.5h Trace Docker ARG / ENV propagation 1h Fix Dockerfile + frontend build integration 1.5h Implement deterministic metadata generation 1h Validation + rebuild testing 1h Documentation + issue notes 0.5h Total Estimate: 6.5 hours
Round to: 6–8 hours
Detailed Work Log
Phase 1 – Investigation (1.5h)
- Inspect frontend About dialog implementation.
- Identify how version/commit metadata is sourced.
- Check usage of:
import.meta.env.env.production- Build-time substitution
- Hardcoded constants
- Compare dev vs production behavior.
Phase 2 – Docker Build Trace (1h)
- Review Dockerfile:
- Check
ARG VERSION - Check
ARG GIT_COMMIT - Confirm values are passed to frontend build stage.
- Check
- Verify whether:
- Build args are injected via
--build-arg - CI passes commit SHA.
- Build args are injected via
- Inspect final production image:
- Confirm embedded static JS bundle contains correct values.
Phase 3 – Implementation Fix (1.5h)
- Ensure:
- Git commit SHA derived via
git rev-parse --short HEAD - Version derived from tag or project version.
- Git commit SHA derived via
- Inject into frontend build deterministically.
- Avoid runtime-only env dependency.
- Update Dockerfile to:
- Explicitly propagate ARG → ENV → frontend build.
- Ensure no stale layer caching issues.
Phase 4 – Deterministic Validation (1h)
- Build from commit A → verify About dialog.
- Make dummy commit B → rebuild → verify update.
- Build with
--no-cache→ confirm correctness. - Confirm behavior inside full Docker Compose stack.
Phase 5 – Documentation (0.5h)
- Document:
- Metadata injection contract.
- Required Docker build args.
- Expected CI variables.
- Add comment in Dockerfile explaining metadata flow.
-
Proposed Scope of Fix
- Audit current frontend metadata injection mechanism.
- Trace build metadata flow:
- Git repo → Docker build args → frontend build → runtime bundle.
- Ensure:
- Deterministic injection in production image.
- No dependency on runtime environment variables (unless intentional).
- Metadata is derived from actual build commit.
- Validate via:
- Clean build without cache.
- Rebuild from different commit.
- Confirm About dialog reflects change.
- Document build metadata contract.
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Version |
1.9.1
|
| Sprints |
n/a
|
| Customer |
n/a
|
Issue Votes (0)
Watchers (3)
Summary
The frontend "About" dialog is expected to display accurate build metadata (e.g. version, commit hash, build timestamp, environment). However, in the production Docker image, build metadata injection is inconsistent or incorrect.
Observed behavior suggests that:
sztab --dev) shows expected metadata.This creates confusion during testing, debugging, and release validation — especially when verifying that a given deployment corresponds to a specific commit or release tag.
Expected Behavior
The About dialog should reliably display:
These values must reflect the exact source revision used to build the production image.
Impact
For a system like Sztab where versioned releases (e.g. 1.9.0) are meaningful, this is a correctness issue.
Acceptance Criteria
docker build --no-cacheproduces correct metadata.Risk Assessment
Low risk. Changes isolated to build process and About dialog metadata display. No impact to runtime business logic.
Notes
This defect is not cosmetic. Accurate build metadata is critical for:
It should be treated as a correctness and traceability issue.