Finding
The release-please flow requires two manual interventions every release because release-please authors its PRs and pushes its tags with the default GITHUB_TOKEN, whose events cannot trigger workflows (GitHub's recursion guard):
- Release PR cannot merge on CI — the required checks (CI/Security/PII/gate-attestation) sit in
action_required and never run on the bot-authored PR, so the release PR is permanently BLOCKED and must be merged with --admin. (v0.1.12 was merged this way: diff is changelog/version-only, code identical to already-green main.)
- Binary build must be dispatched by hand —
release.yml (on: push: tags: v*) never fires from the bot-pushed tag; it must be workflow_dispatch-ed on the tag ref. release.yml's own header documents this ("every release through v0.1.11 shipped zero assets").
Evidence
.github/workflows/release.yml:1-5 (the documented tag-push limitation); #480 (v0.1.12) required --admin + a manual workflow_dispatch --ref v0.1.12.
Why this matters
Every release needs an admin bypass (which our own policy otherwise forbids) plus a manual dispatch — friction that recurs each cut and makes "release" a non-self-service, error-prone step. Pre-v0.1.12 releases shipped zero binary assets because the dispatch step was unknown/skipped.
Desired correction
Author release-please with a GitHub App installation token (or a fine-grained PAT) instead of GITHUB_TOKEN, stored as a repo secret and passed to the release-please action's token: input. Then: (a) the release PR triggers CI normally and merges on green with no --admin; (b) the tag push triggers release.yml automatically, so binaries/SBOM/attestations ship without a manual dispatch. The workflow_dispatch on release.yml can stay as a re-run escape hatch.
Done when: a release PR merges on real green CI with no admin bypass, and its tag auto-builds + attaches release assets with no manual dispatch.
Finding
The release-please flow requires two manual interventions every release because release-please authors its PRs and pushes its tags with the default
GITHUB_TOKEN, whose events cannot trigger workflows (GitHub's recursion guard):action_requiredand never run on the bot-authored PR, so the release PR is permanentlyBLOCKEDand must be merged with--admin. (v0.1.12 was merged this way: diff is changelog/version-only, code identical to already-green main.)release.yml(on: push: tags: v*) never fires from the bot-pushed tag; it must beworkflow_dispatch-ed on the tag ref.release.yml's own header documents this ("every release through v0.1.11 shipped zero assets").Evidence
.github/workflows/release.yml:1-5(the documented tag-push limitation); #480 (v0.1.12) required--admin+ a manualworkflow_dispatch --ref v0.1.12.Why this matters
Every release needs an admin bypass (which our own policy otherwise forbids) plus a manual dispatch — friction that recurs each cut and makes "release" a non-self-service, error-prone step. Pre-v0.1.12 releases shipped zero binary assets because the dispatch step was unknown/skipped.
Desired correction
Author release-please with a GitHub App installation token (or a fine-grained PAT) instead of
GITHUB_TOKEN, stored as a repo secret and passed to the release-please action'stoken:input. Then: (a) the release PR triggers CI normally and merges on green with no--admin; (b) the tag push triggersrelease.ymlautomatically, so binaries/SBOM/attestations ship without a manual dispatch. Theworkflow_dispatchonrelease.ymlcan stay as a re-run escape hatch.Done when: a release PR merges on real green CI with no admin bypass, and its tag auto-builds + attaches release assets with no manual dispatch.