You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Run
Created
Attempt 1
Attempt 2
CI 34727903584, CodeQL 34727903588, conformance 34727903852 on #309
2026-09-13 00:24Z
action_required, triggered by github-actions[bot]
success, triggered by Bccorb at 00:36Z
CI 34766734720, CodeQL 34766734715, conformance 34766735010 on #312
2026-09-13 15:49Z
failure at 16:03:06Z (the merge time of #312), 0 jobs
none
CI 34777624710, CodeQL 34777624672, conformance 34777624991 on #313
2026-09-13 19:25Z
failure at 20:14:17Z (the merge time of #313), 0 jobs
none
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.
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
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.
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.
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.
What happens
The workflow runs on the
changeset-release/mainpull 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 runsfailureat 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:
action_required, triggered bygithub-actions[bot]success, triggered by Bccorb at 00:36Zfailureat 16:03:06Z (the merge time of #312), 0 jobsfailureat 20:14:17Z (the merge time of #313), 0 jobsThe 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
mainare unaffected (Version Changelog PRand CodeQL run and pass), so the releases themselves built, tested and published normally.Why it matters
release.ymlruns lint, format, tests, typecheck and build onmainbefore it versions or tags anything.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).Plan template checksandCheck <id>invalidate.yml) runs only whengithub.head_ref == 'changeset-release/main', so thev0.15.0matrix, 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 thev0.15.0tree (typecheck, lint, format check, tests,expo exportfor iOS and Android) and all pass, so the release is sound, but CI did not establish that.Likely cause
release.ymlhandschangesets/action@v2the repository'sGITHUB_TOKEN(github-token: ${{ secrets.GITHUB_TOKEN }}), so the release branch and PR are authored bygithub-actions[bot]. Runs that actor triggers on a pull request are createdaction_requiredhere rather than started, which is what attempt 1 shows every time. The release workflow already works around the other half of this (aGITHUB_TOKENpush does not trigger workflows, so it invokes the image build directly instead of relying on the tag event).Options
github-actions[bot]start on their own.changesets/actiona token with an identity of its own: a GitHub App installation token (actions/create-github-app-token) or a fine-grained PAT withcontentsandpull-requestswrite. 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 inrelease.ymlgo back to a tag-triggered job.Whichever option wins, it needs applying in each repository listed above; this issue is the record.