In .github/workflows/release.yml, publish declares needs: version-consistency and nothing else. RELEASE-GATE.md §4 — the six checks that ask whether the installation the documentation describes actually works against a clone of the tag — is a written procedure a human runs afterwards, not a workflow dependency.
So pushing a tag creates the release, and the checks that decide whether it deserved to exist run after it already does. If they fail, the correction is a notice on something already published. That is what happened to v0.7.0, whose headline feature was broken in the released artefact.
Blast radius is smaller than it sounds and worth stating precisely: the workflow attaches no assets and there is no npm publish, so what exists prematurely is a tag and a release entry. The entry can be deleted; the tag is what installers resolve and should not be.
Fix: make §4 a job in the release workflow, cloning the tag and running the six checks, and give publish a needs: on it. A release then cannot exist before the checks that qualify it have passed.
Until then the compensating control is manual sequencing — §4 runs against a clone of the tag before any notes are attached — which depends on the operator following it, which is the property a gate exists to remove.
In
.github/workflows/release.yml,publishdeclaresneeds: version-consistencyand nothing else.RELEASE-GATE.md§4 — the six checks that ask whether the installation the documentation describes actually works against a clone of the tag — is a written procedure a human runs afterwards, not a workflow dependency.So pushing a tag creates the release, and the checks that decide whether it deserved to exist run after it already does. If they fail, the correction is a notice on something already published. That is what happened to v0.7.0, whose headline feature was broken in the released artefact.
Blast radius is smaller than it sounds and worth stating precisely: the workflow attaches no assets and there is no
npm publish, so what exists prematurely is a tag and a release entry. The entry can be deleted; the tag is what installers resolve and should not be.Fix: make §4 a job in the release workflow, cloning the tag and running the six checks, and give
publishaneeds:on it. A release then cannot exist before the checks that qualify it have passed.Until then the compensating control is manual sequencing — §4 runs against a clone of the tag before any notes are attached — which depends on the operator following it, which is the property a gate exists to remove.