feat(release): adopt release-toolkit + surface the running version on the dashboard #7
Labels
No labels
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
status/deferred
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/purser#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Motivation
Operator request, 2026-08-05. Purser has no version at all: no tag, no release, and nothing in the UI. Today that cost real time — the running container was six and a half hours older than the fix everyone believed was deployed, and the only way to establish that was comparing a file mtime against an image build timestamp.
A version string on the dashboard makes "is the fix live?" a glance instead of an investigation.
Two halves
1. Adopt
release-toolkit— the house release flow (frankenbit/release-toolkit), same as tmux-tell and the other projects: CHANGELOG discipline,manifest-check,register-check, tagged cuts.2. Display the version in the dashboard footer, and log it at startup beside the existing
purser listeningline.Scope
release-toolkitworkflows wired in.forgejo/workflows/CHANGELOG.mdseeded; first cut tagged from currentmaindebug.ReadBuildInfo(), or-ldflags -X)internal/version/containsversion.goand no test file at all. Restated as an action-AC per § Acceptance-criteria tick discipline.⚠️ Interaction with the build-provenance gap
The sibling tracker (
build: /srv/claude/shipwright/purser-wip) matters here: a version stamped from a build whose source is untracked is a version that names nothing checkable. Sequence the provenance fix first, or the stamp is decoration.Anchor
Operator, 2026-08-05, immediately after the Vault migration. Prompted by the deploy-lag confusion earlier the same day.
pilot referenced this issue2026-08-05 18:45:42 +02:00
AC sweep after
#14merged (8096a7d4) — 4 of 6 met. NOT closing.🔴 And a third gap the ACs do not name: it is merged, not deployed
⚠️ AC4 and AC5 are claims about what a RUNNING service shows. ⛔ Both are true of
mainand false of the deployment. 🔑 Ticking them on source alone would be exactly tonight's lesson inverted —alcatraz-infra#455exists because five people verified againstmainwhile the running service served the old code.📌 So AC4/AC5 are ticked as SOURCE facts and the deployment gap is recorded here rather than hidden inside them. A rebuild closes it; not doing it unannounced while the operator is about to issue certificates.
Remaining
dev/unknownfallback (AC6) — must fail if the fallback chain is broken, per#16Related:
#16(binary release asset + ldflags injection) is the sibling that AC2/AC6 lean on.