ci: release PR workflow runs wait for approval and are marked failed on merge #314

What happens

The workflow runs on the changeset-release/main pull request are created waiting for a maintainer's approval and never start on their own. When the PR is merged without that approval, GitHub marks the pending runs failure at the merge timestamp, with no jobs and the message "This run likely failed because of a workflow file issue" on the run page. The workflow files are fine; nothing under .github/ changed between the runs that passed and the ones that failed.

Today's two release PRs show both outcomes:

The same shape is on #305 (2026-09-12 15:18Z: attempt 1 waiting, attempt 2 approved and green). So every release PR's checks have depended on someone pressing approve before merging; #312 and #313 merged with no checks having run. Pushes to main are unaffected (Version Changelog PR and CodeQL run and pass), so the releases themselves built, tested and published normally.

Why it matters

• A release PR can merge with no CI. For this repository the exposure is small, since release.yml runs lint, format, tests, typecheck and build on main before it versions or tags anything.
• It is not only this repository. The same pattern is on the release PRs of seamless-cli (runs 34780197837, 34780197841, 34780197978 on feat(webauthn)!: refuse synced passkeys by default and restrict models #207), seamless-templates (34777071598, 34777071880 on fix: require a validated service token for external delivery in all environments #92; 34766598886 and 34766599256 still action_required), seamless-auth-react (34766871257, 34766871471 on ci: tag and publish the release automatically after the version PR merges #152), seamless-auth-server (34766382809, 34766383104 on Credentials do not store the AAGUID, blocking metadata lookup and authenticator policy #165) and seamless-auth-types (34734276978 on test: restore skipped connectToDb tests #69).
• In seamless-templates it has teeth: the per-template matrix (Plan template checks and Check <id> in validate.yml) runs only when github.head_ref == 'changeset-release/main', so the v0.15.0 matrix, which is the first to build the Expo starter (expo export), never ran in CI. The last matrix that ran was the approved attempt 2 on 2026-09-12 15:24Z. I ran the starter's matrix steps locally from the v0.15.0 tree (typecheck, lint, format check, tests, expo export for iOS and Android) and all pass, so the release is sound, but CI did not establish that.

Likely cause

release.yml hands changesets/action@v2 the repository's GITHUB_TOKEN (github-token: ${{ secrets.GITHUB_TOKEN }}), so the release branch and PR are authored by github-actions[bot]. Runs that actor triggers on a pull request are created action_required here rather than started, which is what attempt 1 shows every time. The release workflow already works around the other half of this (a GITHUB_TOKEN push does not trigger workflows, so it invokes the image build directly instead of relying on the tag event).

Options

1. Check Settings, Actions, General for the approval requirement that is catching the bot's runs, and whether it can be scoped so same-repository PRs from github-actions[bot] start on their own.
2. Give changesets/action a token with an identity of its own: a GitHub App installation token (actions/create-github-app-token) or a fine-grained PAT with contents and pull-requests write. Runs on the PR then start like any other PR's, and the tag push would trigger workflows normally, which would let the direct image-build invocation in release.yml go back to a tag-triggered job.
3. Until one of those lands: approve the waiting runs on the release PR and wait for green before merging. The two green release PRs this week were exactly that.

Whichever option wins, it needs applying in each repository listed above; this issue is the record.