37e31ffd85
Three corrections from @codex-reviewer-andresmgsl's review of 935a813.
1. `api="${GITHUB_API_URL:-https://api.github.com}"` guessed GitHub when the
variable was absent — driven with a recording curl, it reported success
after POSTing to api.github.com from this forge. That is the "Never
'probably github'" rule, and the same unset-environment refusal #201 just
established for docs-sync. It now refuses before any request, and the test
asserts zero calls were made: refusing after a POST is not refusing.
2. The "never silenced with || true" invariant was still asserted by grepping
the gh line this port removed, so it passed on any REST implementation
including one that swallows a failed POST. It is rebound behaviourally: a
curl that dies at the transport must fail the step. Doing that revealed the
step failed with a bare exit 7 and no sentence, so it now names the failure
— owning the diagnostic is the whole point of the surrounding code.
3. docs/CONSUMERS.md and both caller comments still described `gh workflow
run` as the mechanism. They describe the REST dispatch now, and the manual
bootstrap command carries a forge-neutral curl form beside the gh one: a
cross-forge runbook that sends this forge to a missing binary is wrong even
where the prose around it is right.
Refs #205
2.1 KiB
Fixed
-
.github/workflows/labels.ymlwakes the sweep over REST instead ofgh workflow run, so a board event reconciles within seconds on any forge rather than waiting up to an hour for the scheduled sweep (#205). -
The workflow-dispatch endpoint has the same shape on both forges, so that step no longer decides one: the
CEREMONY_FORGE_CLIENT=ghdeclaration and both inline refusals are gone rather than ported (#205). -
The dispatch supplies its
refexplicitly, because REST has no default branch wheregh workflow runhad one, and refuses without it (#205). -
It takes that ref from the repository, never from
GITHUB_REF_NAME— on apull_request_targetrun that is<n>/merge, which is not a branch (#205). -
A failed dispatch names the endpoint, the ref and the status, and says that an empty
500body from Forgejo means the workflow name or the ref did not resolve — a bare status sends the reader after a server fault that is not there (#205).
Added
-
test/labels-dispatch.test.shextracts the shipped step and executes it against a recording stub, asserting the method, endpoint, ref andinputs.bootstrapactually sent (#205). -
That test also drives the failure path: any non-204 still fails the job, so the misconfiguration alarm the trigger exists to be cannot decay into a warning (#205).
-
An unset
GITHUB_API_URLrefuses before any request instead of defaulting toapi.github.com. Guessing sent this forge's dispatch to GitHub and reported success — the "Never 'probably github'" rule, and the same unset-environment refusal #201 established for docs-sync (#205). -
A dispatch that never reaches the forge names the failure. Letting
set -ecarry curl's exit code out did fail the job, but with a bare status and no sentence (#205). -
docs/CONSUMERS.mdand both caller comments describe the REST dispatch, and the manual bootstrap command carries a forge-neutral form beside theghone — a cross-forge runbook that directs this forge to a missing binary is wrong even where the surrounding prose is right (#205).