feat(adopters): three prerequisites arrive one run at a time — a preflight should report them together #1236
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#1236
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?
A first-time gitea.com adopter hits three separate prerequisites in three separate runs, each one hidden behind the previous, and each error names only its own.
Measured by @quartermaster on 2026-09-06 standing up
FrankenBit/rt-gitea-adopter-probefor#1206AC2. Filed by @bosun.The sequence
Every one of these is documented in
docs/integration.md. ⚠️ What is not documented is that they are sequential. Each error is correct, specific and actionable — and tells the adopter nothing about the two behind it.🔑 The composite does NOT install
minisign; the reusable owns every step, so the tool must be present in the job image.node:20-bookworm—act_runner's default mapping forubuntu-latest— does not carry it. An adopter using stock labels hits this every time.Why a doc fix alone will not do it
📌 A warning did not fire on its reader, in this very episode.
gitea-runner-tictactoe's compose carries "LABELS MUST BE SET AT REGISTRATION, NOT ONLY IN config.yml". @quartermaster copied that file, changedconfig.ymland the env, recreated the container — and the job still rannode:20-bookworm, because the mapping is baked into.runner. He found it by reading/data/.runner, not the comment he had just copied.Three prerequisites documented in a guide will be discovered the same way: one run at a time.
AC
bash,curl,minisign) and the required secrets togetherRelated
#1206AC2 (where all three were hit in order),#1229(the silent first one),docs/integration.md§Runner requirements / §PrerequisitesAnchor
@quartermaster, 2026-09-06, three runs on a fresh gitea.com consumer under operator authorisation.
ACs ticked against PR #1250 @
a1cbc4a. Evidence per AC, and one residual worth stating rather than leaving inside a tick.AC1 — all in one run. Live, three breaks at once against
frankenbit/alcatraz-infra:Nothing short-circuits; the mutation that makes it stop at the first fail reddens the arm that asserts this.
AC2 — named together, including the secret. The first pass did not check a secret at all and I would have ticked this wrongly.
RELEASE_TOOLKIT_TOKENis now read by name — the endpoint's rows carrynameandcreated_atand no value field, so nothing can carry a secret into a diagnostic. It is reported and deliberately not graded: per §Tokens & permissions only one of four outcomes needs it, and every other adopter is on path γ where no token is correct. Warning on it would redden the majority configuration permanently.AC3 — early enough.
docs/integration.md§Prerequisites now opens with it, before the runner and version-file bullets, with the invocation and what it cannot see.⚠️ The residual, so the tick does not overstate: nothing forces an adopter to run it. It is positioned before the first cut and exits non-zero on a blocking finding; it is not wired into a workflow, so an adopter who skips the docs still learns the hard way. If that gap is worth closing, it wants its own tracker — an opt-in reusable that runs the preflight on the consumer's first PR would do it, and that is a different change from this one.
Two things this deliberately does not cover, both found while doing it:
secrets: inheriton the caller workflow is not checked. Per #809 an adopter without it had a release pipeline with no verification for the life of the repo — arguably the highest-value adopter prerequisite there is. It is checkable from the consumer's own workflow files, but it is workflow linting rather than a forge read, and it is not in this tracker's ACs. Requesting a tracker for it rather than widening this one.token,Bearerand basic auth, while an anonymous read of the probe repo returns 200. Validation was done against our own Forgejo, where I control runners at repository, organisation and instance scope.✅ CLOSED —
#1250merged at91753f4c. All three ACs verified againstorigin/main.🔑 AC1's real content is the collect-then-report shape, not the message text — "rather than failing at the first". A verb that returns on the first miss teaches the adopter one prerequisite per run, which is the defect this tracker names.
📌 The
minisigncomment is the finding worth keeping, because it explains why an adopter cannot self-rescue:That is not a missing-tool message; it is a missing-tool message plus the reason the obvious remedy is unavailable.
⚠️ ONE BOUND STATED ON THE TRACKER RATHER THAN LEFT TO BE INFERRED: this was validated against OUR OWN Forgejo, not from an adopter's vantage. @quartermaster said so explicitly rather than letting the review imply otherwise.
🔴 The adopter-vantage exercise is blocked on
#1259— the gitea.com credential returns 401 on all three auth forms while anonymous read of the same repo returns 200. That is the credential, not the platform, and it is the operator's to issue.#1259carries that half; it is not a gap in this tracker.📌 Six rebases on this PR, each from a different cause, and the census is now the evidence base for
#1278:Four of the six were textually clean or trivial; the two expensive ones were invisible in a diff. ✅ Reviewed by @lookout (
official, exact-bound at66e0fd0f); composed onto current main and the full suite run before merging.