docs(runbook): fix the registry-retention rehearsal command and record the auto-update warning #341
Inga granskare
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-infra!341
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "docs/runbook-corrections"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
Closes #316, closes #318.
Two places where the documentation described something that was not true.
#316 — the registry-retention dry-run rehearsal command in the runbook fails, which means it has
probably never been run as written. The token path was traced through the unit rather than guessed:
EnvironmentFilepoints at a0600file owned bygitborg, the script is0750, and the guardthat fires is the script's own
${FORGEJO_TOKEN:?…}. So the invocation has to both run asgitborgand source the file inside thatsudo. The corrected form matches an idiom already provenelsewhere in the same runbook.
Reproduced locally with byte-shaped stand-ins — same env-file layout, same guard, same file modes:
the documented form fails with the exact reported message and exit 1; the corrected one exits 0,
including the backslash continuation inside single quotes, which a copy-paste reproduces verbatim.
Not run against production.
A scan for the same defect elsewhere found this was the only affected entry: every other
env-file job documents
systemctl --user start, where systemd reads theEnvironmentFileitself, sothe problem cannot arise. That distinction is now written down so it does not get re-lost.
#318 — the
MONITOR_*propagation warning is genuine noise, not a masked bug, and is nowdocumented as expected. Measured rather than estimated: 385 occurrences in 24 h, spaced
~157–205 s, i.e. one per auto-update timer tick rather than per deploy.
The mechanism holds up: the verify unit is named on both
OnSuccess=andOnFailure=, and systemdonly propagates
MONITOR_*when there is exactly one trigger source. Decisively,grep -rn "MONITOR_"across the whole repo returns nothing — the verify script never reads those variables,determining outcomes from
podman inspectplus a journal scan, precisely because a rollback exits 0.So the propagation was never load-bearing.
Recorded alongside it: the one real constraint this creates (the verifier cannot learn which hook
invoked it, so a future failed-versus-succeeded branch needs two units), and an explicit note not
to drop
OnFailure=just to silence the warning.Verification
markdownlint 0 issues, Prettier clean, shellcheck exit 0.
pnpm ansible:checkcould not run in theworktree (needs the vault password file); the only Ansible change is a comment block, verified to
contain no Jinja delimiters and to be entirely
#-prefixed.