[johnnyhuy]

Root cause

CI never executes on release-please PRs because release-please.yml runs googleapis/release-please-action@v4 with the default GITHUB_TOKEN. GitHub treats pull_request events produced by GITHUB_TOKEN specially: "when a workflow using GITHUB_TOKEN creates or updates a pull request, the resulting pull_request event creates workflow runs in an approval-required state ... a user with write access to the repository can start the runs by selecting Approve workflows to run" (GitHub docs: Triggering a workflow). Every CI run for a PR opened/updated by github-actions[bot] therefore lands with zero jobs and the banner "This workflow is awaiting approval from a maintainer in #N" (verified in run 36433648525, PR #47). Nobody clicks Approve; the release PRs are merged seconds later, which dismisses the held run as failure with zero jobs and no logs (runs left unmerged expire ~30 days later: 30577984653 / 30578760010 / 30579654886 from 2026-07-30 all concluded failure on 2026-08-29). Human PRs (johnnyhuy, MEMBER) and Dependabot PRs are not created via GITHUB_TOKEN, so their runs execute normally (6 jobs). The CI workflow itself is not at fault: ci.yml is byte-identical on the release branches and main, has no paths or job-level if: filters, and repo Actions policy is allowed_actions: all.

Evidence

Run	PR	Conclusion	Jobs	Note
36433648525	#47 (open)	action_required	0	"awaiting approval from a maintainer in #47"
35480090136	#43	failure	0	concluded 00:57:03 == PR merged 00:57:03
35479119308	#41	failure	0	concluded 00:34:27 == PR merged 00:34:26
35477198061	#39	failure	0	concluded 23:51:15 == PR merged 23:51:14
35431206016	#35	failure	0	concluded 08:09:03 == PR merged 08:09:02
35479962865	#42 (human)	success	6	normal PR

Fix in this PR

One line in .github/workflows/release-please.yml: pass an optional RELEASE_PLEASE_TOKEN to the action, falling back to github.token when the secret is absent (behaviour is unchanged until the secret exists). With the secret set, release PRs are authored by a trusted identity and pull_request workflows run automatically without the approval prompt (GitHub docs: "Using one of these alternatives [GitHub App installation access token or a personal access token] also lets pull_request workflows run automatically (without the approval prompt described above) when the pull request is created or updated by automation"; see also release-please-action: Token).

Maintainer action required to activate the fix:

1. Create a fine-grained PAT (or GitHub App installation token) on a bot or maintainer account with Contents: read/write and Pull requests: read/write, scoped to this repo. (release-please-config.json only touches CHANGELOG.md, .release-please-manifest.json and pkg/version/version.go, so workflows write is not needed.)
2. Store it as the repository secret RELEASE_PLEASE_TOKEN (Settings → Secrets and variables → Actions).
3. Done — the next Release Please run picks it up; no further code change.

The token owner must have write access so the PR author association is MEMBER/COLLABORATOR (as with human PRs today). The github.token fallback keeps release automation working if the secret is ever removed.

Immediate unblock for the open release PR (#47)

Open the workflow run or the PR merge box and click Approve workflows to run — the six CI jobs will then execute. That is the manual workaround for every release PR until the secret exists.

Related consequence of the same root cause

Releases published by github-actions[bot] (v0.1.2, v0.1.3, v2026.9.0, v2026.9.2) never triggered release.yml either: release events produced by GITHUB_TOKEN are suppressed ("workflows normally triggered by release.created events will also not run"). Only v0.1.1 (published by johnnyhuy) ever ran the Release workflow. The token change fixes that path as well.

Validation

• actionlint passes; YAML round-trip confirms token: ${{ secrets.RELEASE_PLEASE_TOKEN || github.token }}.
• CI on this PR is a normal human PR and runs all six jobs (watch gh run list --branch ci/release-pr-checks), confirming trigger config is untouched.
• End-to-end behaviour with the secret set can only be verified after the secret is created; until then the fallback preserves current semantics.

Deliberately not done: pull_request_target, workflow_run auto-approve of the gate, or any change that weakens/skips checks for all PRs.