What happens
binaries.yml and install.yml both declare:
on:
release:
types: [published]They have never once run from that trigger. Every run of either is
workflow_dispatch. Checked on the v0.6.3 release: release.yml finished
green, the GitHub release existed — and the release page had zero assets
until the workflow was dispatched by hand.
Why
release.yml creates the release with GITHUB_TOKEN. GitHub does not start
workflow runs from events raised by that token — a deliberate anti-recursion
rule. So a release created by the pipeline can never trigger the workflows that
are supposed to react to it.
What it costs
Between the tag and someone remembering to dispatch two workflows by hand:
- the release has no downloadable binaries for any platform,
brew install vyncint/tap/mossaic still installs the previous version,
because the tap is regenerated by the formula job inside binaries.yml,- nothing verifies the published crate installs.
That window has existed for 0.6.0, 0.6.1, 0.6.2 and 0.6.3. It closed each time
only because the release was being watched.
Options
- Call them from
release.yml with workflow_call, the way it already
reuses ci.yml. Same one pipeline, no second trigger, nothing to remember.
The tag is already known there.
- Create the release with a PAT so the
published event is raised by a
real identity. Works, but adds a stored secret to a repository that
deliberately has none — RELEASING.md says so twice.
- Leave the trigger and document the dispatch in
RELEASING.md as step 5.
Honest, but it is a checklist item that has to be right every time, and the
failure is silent.
Option 1 looks right: it makes the artifacts part of the release rather than a
thing that happens near it, and it deletes the release: trigger rather than
leaving one that does not work.
Done when
Tagging vX.Y.Z produces the crates.io publish, the GitHub release, the five
platform archives and the updated tap formula, with no manual dispatch — and
RELEASING.md no longer needs a step nobody can forget.
What happens
binaries.ymlandinstall.ymlboth declare:They have never once run from that trigger. Every run of either is
workflow_dispatch. Checked on the v0.6.3 release:release.ymlfinishedgreen, the GitHub release existed — and the release page had zero assets
until the workflow was dispatched by hand.
Why
release.ymlcreates the release withGITHUB_TOKEN. GitHub does not startworkflow runs from events raised by that token — a deliberate anti-recursion
rule. So a release created by the pipeline can never trigger the workflows that
are supposed to react to it.
What it costs
Between the tag and someone remembering to dispatch two workflows by hand:
brew install vyncint/tap/mossaicstill installs the previous version,because the tap is regenerated by the
formulajob insidebinaries.yml,That window has existed for 0.6.0, 0.6.1, 0.6.2 and 0.6.3. It closed each time
only because the release was being watched.
Options
release.ymlwithworkflow_call, the way it alreadyreuses
ci.yml. Same one pipeline, no second trigger, nothing to remember.The tag is already known there.
publishedevent is raised by areal identity. Works, but adds a stored secret to a repository that
deliberately has none —
RELEASING.mdsays so twice.RELEASING.mdas step 5.Honest, but it is a checklist item that has to be right every time, and the
failure is silent.
Option 1 looks right: it makes the artifacts part of the release rather than a
thing that happens near it, and it deletes the
release:trigger rather thanleaving one that does not work.
Done when
Tagging
vX.Y.Zproduces the crates.io publish, the GitHub release, the fiveplatform archives and the updated tap formula, with no manual dispatch — and
RELEASING.mdno longer needs a step nobody can forget.