#350 (merged) made the CI-trigger scheduler (ci-trigger.yml) dispatch ci.yml with the built-in GITHUB_TOKEN (gh workflow run), on the claim that workflow_dispatch is anti-recursion-exempt. In practice a GITHUB_TOKEN-triggered workflow requires MANUAL AUTHORIZATION — so auto-updated PRs sit with un-run CI pending approval (observed on #285). This is why the original #349 design used a PAT.
Fix — separation of concerns
ci-trigger.yml (scheduler): trigger CI with the PATsecrets.AUTOUPDATE_TOKEN (not GITHUB_TOKEN). A PAT-triggered run runs as the authorized owner → no approval gate.
autoupdate.yml: keep the branch UPDATE on GITHUB_TOKEN (unchanged — update must NOT retrigger; that kills the cascade).
So: updates = GITHUB_TOKEN, triggering = PAT, cleanly separated.
Do
ci-trigger.yml: change the trigger step GH_TOKEN from ${{ github.token }} to ${{ secrets.AUTOUPDATE_TOKEN }} (AUTOUPDATE_TOKEN already exists — #350 left it unused; re-use it). Fail-open if the secret is absent.
Fix the now-wrong "no PAT needed / workflow_dispatch exempt" comments in ci-trigger.yml + docs.
Keep autoupdate.yml on GITHUB_TOKEN.
Validate: YAML parse; traffic-control unit tests still pass.
P2 — blocks auto-updated PRs' CI. Coordinator reviews before arming (core CI flow).
#350 (merged) made the CI-trigger scheduler (`ci-trigger.yml`) dispatch `ci.yml` with the built-in **GITHUB_TOKEN** (`gh workflow run`), on the claim that `workflow_dispatch` is anti-recursion-exempt. In practice a **GITHUB_TOKEN-triggered workflow requires MANUAL AUTHORIZATION** — so auto-updated PRs sit with un-run CI pending approval (observed on #285). This is why the original #349 design used a PAT.
## Fix — separation of concerns
- **`ci-trigger.yml` (scheduler): trigger CI with the PAT** `secrets.AUTOUPDATE_TOKEN` (not GITHUB_TOKEN). A PAT-triggered run runs as the authorized owner → no approval gate.
- **`autoupdate.yml`: keep the branch UPDATE on GITHUB_TOKEN** (unchanged — update must NOT retrigger; that kills the cascade).
So: **updates = GITHUB_TOKEN, triggering = PAT**, cleanly separated.
## Do
- `ci-trigger.yml`: change the trigger step `GH_TOKEN` from `${{ github.token }}` to `${{ secrets.AUTOUPDATE_TOKEN }}` (AUTOUPDATE_TOKEN already exists — #350 left it unused; re-use it). Fail-open if the secret is absent.
- Fix the now-wrong "no PAT needed / workflow_dispatch exempt" comments in `ci-trigger.yml` + docs.
- Keep `autoupdate.yml` on GITHUB_TOKEN.
- Validate: YAML parse; traffic-control unit tests still pass.
P2 — blocks auto-updated PRs' CI. Coordinator reviews before arming (core CI flow).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
#350 (merged) made the CI-trigger scheduler (
ci-trigger.yml) dispatchci.ymlwith the built-in GITHUB_TOKEN (gh workflow run), on the claim thatworkflow_dispatchis anti-recursion-exempt. In practice a GITHUB_TOKEN-triggered workflow requires MANUAL AUTHORIZATION — so auto-updated PRs sit with un-run CI pending approval (observed on #285). This is why the original #349 design used a PAT.Fix — separation of concerns
ci-trigger.yml(scheduler): trigger CI with the PATsecrets.AUTOUPDATE_TOKEN(not GITHUB_TOKEN). A PAT-triggered run runs as the authorized owner → no approval gate.autoupdate.yml: keep the branch UPDATE on GITHUB_TOKEN (unchanged — update must NOT retrigger; that kills the cascade).So: updates = GITHUB_TOKEN, triggering = PAT, cleanly separated.
Do
ci-trigger.yml: change the trigger stepGH_TOKENfrom${{ github.token }}to${{ secrets.AUTOUPDATE_TOKEN }}(AUTOUPDATE_TOKEN already exists — #350 left it unused; re-use it). Fail-open if the secret is absent.ci-trigger.yml+ docs.autoupdate.ymlon GITHUB_TOKEN.P2 — blocks auto-updated PRs' CI. Coordinator reviews before arming (core CI flow).