Add ADR 0019 (frontend release pipeline) and releasing.md fixes#202
Merged
Conversation
The GHCR image path was capitalised inconsistently with how the workflow actually publishes it. Example versions across the doc were stale relative to the latest released tags, making the procedure read as if it had not been used. - Lowercase ghcr.io/diamondlightsource/smartem-decisions - Bump example versions to a plausible next-stable for each package
The smartem-frontend repository has had no release pipeline, no tags,
no published artefacts, and no Kubernetes manifest deploying it in any
environment. With the monorepo restructure (ADR 0017) complete and the
legacy app due for retirement, this is the right moment to commit to a
release shape that matches the rest of the workspace.
Key decisions captured:
- Independent frontend semver with a build-time /version stamp carrying
the backend OpenAPI info.version, allowing FE/BE versions to drift
while keeping compatibility observable at runtime.
- smartem-frontend-v{semver} tag prefix, RC-on-main + stable-on-tag +
workflow_dispatch, matching release-smartem-decisions.yml.
- nginx:1.30-alpine for SPA serving — defended against Caddy,
freenginx, and Node-runtime serving, with a note that no DLS-wide
pattern exists either way.
- GHCR-only artefacts; no PyPI, no npm publish, no Windows exe.
- Build target apps/smartem only; legacy excluded from the pipeline
and to be purged after first successful production deploy.
Implementation, k8s manifests, ingress rule, and the BE /version
endpoint contract are explicit follow-ups outside the scope of this
ADR. ADR 0018 is reserved for the in-flight agent auth work.
github-actions
Bot
added
the
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related documentation changes for the SmartEM release story, in
two commits so each can be reviewed independently:
docs(release)— fix accuracy issues indocs/operations/releasing.md: lowercase the GHCR image path(matches what the workflow actually publishes) and refresh example
version numbers, which had drifted away from the actual latest tags
for each package.
docs(adr)— add ADR-0019 defining a release and deploymentpipeline for
smartem-frontend, the missing piece in the workspacerelease story. The ADR commits to:
/versionstamp carrying the backend OpenAPI
info.version, so FE/BEcompatibility is observable at runtime without forcing lockstep
bumps.
smartem-frontend-v{semver}tag prefix; RC-on-main +stable-on-tag +
workflow_dispatch, matching the shape ofrelease-smartem-decisions.yml.nginx:1.30-alpinefor static SPA serving — defended againstCaddy, freenginx, and Node-runtime serving in the Alternatives
Considered section.
apps/smartemonly; legacy excluded.ADR-0018 is intentionally skipped — that number is reserved for
the in-flight agent authentication ADR.
Implementation of the workflow, Dockerfile replacement, k8s manifests,
ingress rule, and the backend
/versionendpoint contract are listedas follow-ups in the ADR and are out of scope here.
Test plan
at
/docs/decision-records/decisions/0019-smartem-frontend-release-pipelineDecision Records
docs/operations/releasing.mdstill renders with theupdated examples
Related
docs/operations/releasing.mdonce the pipeline lands