ceremony/actions/labels-reconcile
clad2 6986deede7
Some checks failed
CI / test (pull_request) Failing after 33s
CI / release-exercise (pull_request) Successful in 11s
CI / self-guards (pull_request) Successful in 7s
CI / action-exercise (pull_request) Successful in 6s
CI / docs-sync-exercise (pull_request) Successful in 6s
Refs guard / refs-not-closing (pull_request) Successful in 7s
labels / labels (pull_request) Successful in 8s
fix(labels): the bootstrap keys on the BOOTSTRAP input, never the event name
The venue drill caught what no hermetic test had: with the workflow_call
bridge delivering "no" perfectly, drill runs 16/17 still bootstrapped. The
script gated on GITHUB_EVENT_NAME = workflow_dispatch and never read
$BOOTSTRAP at all; the wrapper's only coupling was exporting the event name
for yes. Correct while an operator's manual dispatch was the only dispatch
there was — inert from #209 on, when the trigger job made every machine wake
a workflow_dispatch event. Runs 459/523 bootstrapped for this reason, not
for the input-delivery defect, which is real but was never the operative
cause of the observed re-upserts.

The script now gates on ${BOOTSTRAP:-no} = yes; the wrapper passes the input
through untouched; the hermetic suite pins the exact regression pair (a
dispatch event with no/unset creates and deletes nothing) alongside the
yes path's full create+delete assertions.

Refs #215
2026-08-05 21:32:21 +00:00
..
action.yml fix(labels): the bootstrap keys on the BOOTSTRAP input, never the event name 2026-08-05 21:32:21 +00:00
labels-reconcile.sh fix(labels): the bootstrap keys on the BOOTSTRAP input, never the event name 2026-08-05 21:32:21 +00:00