feat(release-pr-checks): make the release-PR healer a fleet reusable - #56
Merged
Conversation
release-please creates its PR with GITHUB_TOKEN and GitHub raises no
workflow-triggering events for that token, so every release PR arrives with its
required contexts ABSENT rather than red. Branch protection holds such a PR
forever: there is nothing to re-run and nothing to approve.
aletheia has carried the only healer for months. Seventeen other repos run
release-please with none, and nothing in those repos could reveal the gap.
Measured 2026-08-26: four release PRs stuck 8 days with an empty
statusCheckRollup while five runs each sat at action_required.
Three changes make the aletheia original shareable:
- REPO comes from GITHUB_REPOSITORY, which inside a workflow_call job is the
CALLER's repository. Validated in main() rather than at import, so the unit
tests still load the module outside an Actions environment; an empty value is
a loud failure, because every gh call would otherwise target "" and report
"no open release PR" -- a green run that healed nothing.
- REQUIRED_CONTEXT_WORKFLOWS becomes a caller input. It scopes only the fallback
dispatch path; approval queries every held run at the head SHA regardless of
workflow, so the primary path needs no per-repo configuration.
- The script is vendored here and checked out explicitly from this repository,
since a workflow_call job's default checkout fetches the caller, where it does
not exist.
The PAT is gone, and this is the substantive correction. The ancestor asserted
that GITHUB_TOKEN "is documented to be refused for run approval" and fell back
to a FLEET_REPO_TOKEN secret. That assertion was never tested and is false: a
job holding only GITHUB_TOKEN with actions: write posted to
/actions/runs/{id}/approve for a genuinely held run, received 201, and the run
moved action_required -> in_progress. A control probe against a run not awaiting
approval returned 403 "This workflow run is not waiting for approval" -- a state
message, not "Resource not accessible by integration", so authorization had
already passed. Consuming repos therefore need no shared credential, which
removes a 17-repo secret rollout that was about to be provisioned on an
untested premise.
Adding the missing-repository guard made three tests fail and revealed that two
others had been passing for the wrong reason -- they expect 1 and were getting
it from the new guard rather than from the condition each asserts. Reporting now
pins REPO in setUp, and the guard has its own test asserting that an unset
repository fails loudly instead of sweeping nothing. 12 tests pass.Uh oh!
There was an error while loading. Please reload this page.
forkwright added a commit
to forkwright/akroasis
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs here arrive with their required contexts **absent rather than red**, because release-please creates them with `GITHUB_TOKEN` and GitHub raises no workflow-triggering events for that token. Branch protection holds a PR with a missing context forever. ## Evidence #465 (`chore(main): release 0.6.2`) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while five workflow runs waited at `action_required`. `gh api repos/forkwright/akroasis/actions/runs?status=action_required` currently returns **51** held runs. ## Why this matters A missing check is worse than a failing one — a red check advertises itself; an absent one looks exactly like a PR still waiting on CI. Releases stop, and nothing surfaces the cause. ## Desired correction Adopt the reusable healer merged as `forkwright/.github#56`. This file asks for it and declares nothing about how it works, so it cannot drift from the other 17 repos that will carry it. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing It is not the usual boilerplate. For `workflow_call`, the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. `actions: write` approves the held runs; `pull-requests: read` finds the release PR and its head SHA. Nothing here writes to a PR. ## Note This is the first adopter, deliberately — akroasis is the only repo with an open stuck release PR right now, so it is where the end-to-end path can actually be observed rather than assumed. The remaining 17 follow once a run here is read. Independent of this, #465 is also blocked by a real compile failure that #471 fixes; the two are unrelated causes on the same PR. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/theatron
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/sphragis
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/koinon
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/zetesis
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/epistole
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/logismos
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/heurema
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/hamma
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/epitelesis
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/harmonia
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/thumos
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
to forkwright/typikon
that referenced
this pull request
Aug 26, 2026
## Finding Release PRs in this repo arrive with their required contexts **absent rather than red**. `release-please` creates its PR with `GITHUB_TOKEN`, and GitHub raises no workflow-triggering events for that token, so branch protection holds a PR with a missing context forever — nothing to re-run, nothing to approve. ## Evidence Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733, gnomon#68) sat **8 days** at `mergeStateStatus: BLOCKED` with an **empty** `statusCheckRollup` while their workflow runs waited at `action_required`. aletheia has carried the only healer for months. A file-existence check found `release-pr-checks.yml` **404 in all 17 other release-please repos**, and nothing visible from inside any of them revealed the gap. ## Why this matters A missing check is worse than a failing one. A red check advertises itself; an absent one looks exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears to be waiting on CI. ## Desired correction Adopt the reusable healer (`forkwright/.github#56`). This file asks for it and declares nothing about how it works, so it cannot drift from the other adopters. **Done when:** a subsequent release PR here reaches a non-empty `statusCheckRollup` without a human approving runs by hand. ## The permissions block is load-bearing Not the usual boilerplate. For `workflow_call` the caller's `permissions` is a **cap** — a called workflow can only *downgrade* the token, never upgrade it. A caller declaring the customary `contents: read` alone would leave the healer unable to approve a single run, and the only symptom would be a release that stayed stuck. ## Proven, not assumed The whole path was exercised on akroasis before this rollout: - `Actions: write` confirmed present in the reusable's job token, so the caller's grant does reach it (run 32982564877). - `GITHUB_REPOSITORY` resolves to the **caller** — the healer reported `#465 at b75af1a6f`, akroasis's own release PR, while running from `forkwright/.github`. - The `workflow_run` trigger fired automatically on release-please completion and superseded a manual dispatch via `cancel-in-progress`, exactly as designed. - `GITHUB_TOKEN` + `actions: write` approving a genuinely held run: **`201`**, and the run moved `action_required` → `in_progress` (probed on zetesis run 31286567826). **No PAT and no repo secret are required** — an assertion to the contrary lived unexamined in aletheia's copy for months and is false. Co-authored-by: forkwright <cody@forkwright.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finding
release-pleasecreates its PR withGITHUB_TOKEN, and GitHub raises noworkflow-triggering events for that token. Every release PR therefore arrives with its required
contexts absent rather than red, and branch protection holds a PR with a missing context
forever — nothing to re-run, nothing to approve.
aletheia has carried the only healer for months. 17 other repos run release-please with none,
and nothing visible from inside those repos reveals the gap.
Evidence
Measured 2026-08-26: akroasis#465, epistole#127, harmonia#733, gnomon#68 — all open 8 days, all
mergeStateStatus: BLOCKED, all with an emptystatusCheckRollupwhile five workflow runseach sat at
action_required. Aci_hold_sweepapproving the held runs took harmonia#733 fromrollup=0to 15 checks andCLEANwithin minutes; it and epistole#127 have since merged.File-existence check across the fleet:
release-pr-checks.ymlis 404 in all 18 release-pleaserepos except aletheia, and absent from this repo.
Why this matters
A missing check is worse than a failing one. A red check advertises itself; an absent one looks
exactly like a PR that has not finished. The releases stopped for over a week and the only symptom
was a PR that appeared to be waiting on CI.
Desired correction
Three changes make aletheia's original shareable:
REPOfromGITHUB_REPOSITORY, which inside aworkflow_calljob is the caller'srepository. Validated in
main()rather than at import, so the unit tests still load the moduleoutside an Actions environment. An empty value fails loudly — every
ghcall would otherwisetarget
"", list nothing, and report "no open release PR": a green run that healed nothing,which is the exact silent-success shape this tool exists to end.
REQUIRED_CONTEXT_WORKFLOWSbecomes a caller input. It scopes only the fallback dispatchpath;
approvequeries every held run at the head SHA regardless of workflow, so the primarypath needs no per-repo config and stays correct where the list is wrong.
workflow_calljob's default checkout fetches the caller, where it does not exist.Done when: a repo that was 404 on the healer carries a non-empty
statusCheckRollupon itsnext release PR.
The substantive correction: no PAT is required
The ancestor asserted that
GITHUB_TOKEN"is documented to be refused for run approval" and fellback to a
FLEET_REPO_TOKENsecret. That assertion was never tested, and it is false.Probed directly (
forkwright/zetesis, run 31286567826, a genuinely held run on a superseded headwith zero open PRs):
GITHUB_TOKEN+actions: write→POST /actions/runs/31286567826/approve201, and the run movedaction_required→in_progress403 "This workflow run is not waiting for approval"The control matters: a refused token returns
Resource not accessible by integration. Astate-specific message means authorization had already passed.
Consuming repos therefore need no shared credential, and
secrets:is absent from the reusablebecause there is nothing to inherit. This removed a 17-repo secret rollout that was about to be
provisioned on an untested premise.
Tests
Adding the missing-repository guard made three tests fail — and revealed that two others had
been passing for the wrong reason, expecting
1and receiving it from the new guard rather thanfrom the condition each was written to assert.
Reportingnow pinsREPOinsetUp, and theguard has its own test asserting that an unset repository fails loudly instead of sweeping nothing.
12 tests pass locally.
Follow-up, not in this PR
Consumer caller files for the 18 repos, once this merges. aletheia's own copy should then be
retired in favour of this one — that is
@k3-aletheia's lane, so it is flagged rather than donehere, along with the now-incorrect PAT comment in its file.