ci: pass PAT to action-gh-release so release events propagate #44

2026-04-08T23:22:11+08:00

razvandimescu commented

2026-04-08 23:22:11 +08:00

(Migrated from github.com)

Why

GitHub Actions deliberately does not propagate workflow events triggered by the default GITHUB_TOKEN — a safety feature against infinite loops. `softprops/action-gh-release` falls back to GITHUB_TOKEN when no token is supplied, so the resulting release: published event is silently swallowed and never reaches downstream workflows like homebrew-bump.yml.

Reference: GitHub docs — Triggering a workflow from a workflow:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run.

How we found it

Discovered while shipping v0.10.1 (the release that closes #35 + ships #41 #40 #42 #43):

Step	Result
`git tag v0.10.1` pushed	✓
`release.yml` triggered on tag push	✓
Build matrix (5 platforms)	✓
`cargo publish` to crates.io	✓
`softprops/action-gh-release` created the GitHub release	✓
`homebrew-bump.yml` auto-fired on `release: published`	✗ silent no-op
Brew tap formula stayed at v0.10.0	✗ users on `brew upgrade numa` stuck on v0.10.0

Had to manually run gh workflow run homebrew-bump.yml -f version=0.10.1 to actually update the tap. Latent bug since #39 landed today.

Fix

Pass HOMEBREW_TAP_GITHUB_TOKEN explicitly to softprops/action-gh-release. This secret is already a PAT — it has to be, because homebrew-bump.yml uses it to git clone and push to a different repo (razvandimescu/homebrew-tap), which GITHUB_TOKEN cannot do (no cross-repo scope). Reusing it for release creation keeps the secret surface flat (no second PAT).

PAT-authored release events ARE propagated by GitHub Actions — that's the documented escape hatch from the no-propagation rule.

What this affects

v0.10.1 (already shipped): not affected. Bumped manually.
v0.10.2 and later: brew tap will auto-bump on release without manual intervention.
Existing PR pipelines (#41/#40/#42/#43 style): not affected — this only changes the release workflow's tag-trigger path.

Test plan

This is a CI workflow change. The fix can only be exercised end-to-end by cutting an actual release, which we won't do until v0.10.2 ships organically. Static verification:

YAML syntax valid (release.yml builds OK in editor; CI will also validate)
HOMEBREW_TAP_GITHUB_TOKEN secret already exists in repo (homebrew-bump.yml uses it successfully today)
softprops/action-gh-release@v2 docs confirm token is the documented input for overriding GITHUB_TOKEN
CI green on the PR (linter only — no behavior to test)
First real release (v0.10.2+) verifies that the brew tap auto-bumps without manual gh workflow run

Why not a fancier fix

I considered:

repository_dispatch from release.yml → homebrew-bump.yml: cleaner separation but requires editing both workflows + adding a repository_dispatch trigger. More moving parts for the same outcome.
Inline the brew bump into release.yml: couples release + tap update into one workflow. Worse for separation of concerns, also still needs the PAT for cross-repo push.
A second PAT specifically for the release: more secrets to rotate, no benefit since we already have a working PAT for the same scope.

The single-line token: addition is the smallest change with the largest payoff.

🤖 Generated with Claude Code

## Why GitHub Actions deliberately does not propagate workflow events triggered by the default `GITHUB_TOKEN` — a safety feature against infinite loops. \`softprops/action-gh-release\` falls back to `GITHUB_TOKEN` when no `token` is supplied, so the resulting `release: published` event is silently swallowed and never reaches downstream workflows like `homebrew-bump.yml`. [Reference: GitHub docs — Triggering a workflow from a workflow](https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow): > When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. ## How we found it Discovered while shipping v0.10.1 (the release that closes #35 + ships #41 #40 #42 #43): | Step | Result | |---|---| | `git tag v0.10.1` pushed | ✓ | | `release.yml` triggered on tag push | ✓ | | Build matrix (5 platforms) | ✓ | | `cargo publish` to crates.io | ✓ | | `softprops/action-gh-release` created the GitHub release | ✓ | | **`homebrew-bump.yml` auto-fired on `release: published`** | **✗ silent no-op** | | **Brew tap formula stayed at v0.10.0** | **✗ users on `brew upgrade numa` stuck on v0.10.0** | Had to manually run `gh workflow run homebrew-bump.yml -f version=0.10.1` to actually update the tap. Latent bug since #39 landed today. ## Fix Pass `HOMEBREW_TAP_GITHUB_TOKEN` explicitly to `softprops/action-gh-release`. This secret is already a PAT — it has to be, because `homebrew-bump.yml` uses it to `git clone` and push to a *different* repo (`razvandimescu/homebrew-tap`), which `GITHUB_TOKEN` cannot do (no cross-repo scope). Reusing it for release creation keeps the secret surface flat (no second PAT). PAT-authored release events ARE propagated by GitHub Actions — that's the documented escape hatch from the no-propagation rule. ## What this affects - **v0.10.1 (already shipped)**: not affected. Bumped manually. - **v0.10.2 and later**: brew tap will auto-bump on release without manual intervention. - **Existing PR pipelines (#41/#40/#42/#43 style)**: not affected — this only changes the release workflow's tag-trigger path. ## Test plan This is a CI workflow change. The fix can only be exercised end-to-end by cutting an actual release, which we won't do until v0.10.2 ships organically. Static verification: - [x] YAML syntax valid (release.yml builds OK in editor; CI will also validate) - [x] `HOMEBREW_TAP_GITHUB_TOKEN` secret already exists in repo (homebrew-bump.yml uses it successfully today) - [x] [softprops/action-gh-release@v2 docs](https://github.com/softprops/action-gh-release#%EF%B8%8F-customizing) confirm `token` is the documented input for overriding GITHUB_TOKEN - [ ] CI green on the PR (linter only — no behavior to test) - [ ] First real release (v0.10.2+) verifies that the brew tap auto-bumps without manual `gh workflow run` ## Why not a fancier fix I considered: 1. **`repository_dispatch` from release.yml → homebrew-bump.yml**: cleaner separation but requires editing both workflows + adding a `repository_dispatch` trigger. More moving parts for the same outcome. 2. **Inline the brew bump into `release.yml`**: couples release + tap update into one workflow. Worse for separation of concerns, also still needs the PAT for cross-repo push. 3. **A second PAT specifically for the release**: more secrets to rotate, no benefit since we already have a working PAT for the same scope. The single-line `token:` addition is the smallest change with the largest payoff. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dearsky/numa#44