.github/workflows/autoupdate.yml only triggers on push to main. So a PR opened during a quiet period (no subsequent merge to main) is never auto-updated and sits behind main until the next merge — or a manual "Update branch" click. Observed with #256 (lane 4), which opened after the last merge and had to be updated by hand.
(Note: branch protection is strict: false, so a behind PR still merges once its checks pass — this isn't a merge blocker, but auto-updating a fresh PR means its CI runs against the latest main immediately, catching integration breaks sooner.)
Fix
Add a pull_request trigger alongside the existing push:
Include opened (the #256 case), reopened, ready_for_review (draft → ready while behind).
Do NOT add synchronize — it fires on every commit push (including the action's own branch updates), causing wasteful re-runs and near-loops.
Preserve everything else: environment: CI_CD, GITHUB_TOKEN: ${{ secrets.AUTOUPDATE_TOKEN || secrets.GITHUB_TOKEN }}, PR_FILTER: "all", permissions, and the concurrency group (for pull_request events github.ref is refs/pull/N/merge, so each PR gets its own group — no cross-cancellation; fine as-is).
Same-repo branches only (no forks), so the CI_CD environment secret remains available on pull_request events.
Definition of done
This is a workflow file — no app-level unit/E2E test applies. DoD: valid YAML + correct trigger, and the PR's own CI (Debug build / Unit tests / CI passed) green. Validated post-merge by observing the workflow fire on the next opened PR and update behind PRs.
## Problem
`.github/workflows/autoupdate.yml` only triggers on **`push` to main**. So a PR opened **during a quiet period** (no subsequent merge to main) is never auto-updated and sits behind `main` until the next merge — or a manual "Update branch" click. Observed with **#256** (lane 4), which opened after the last merge and had to be updated by hand.
(Note: branch protection is `strict: false`, so a behind PR still merges once its checks pass — this isn't a merge blocker, but auto-updating a fresh PR means its CI runs against the latest `main` immediately, catching integration breaks sooner.)
## Fix
Add a `pull_request` trigger alongside the existing `push`:
```yaml
on:
push:
branches: [main]
pull_request:
types: [opened, reopened, ready_for_review]
```
- Include `opened` (the #256 case), `reopened`, `ready_for_review` (draft → ready while behind).
- **Do NOT add `synchronize`** — it fires on every commit push (including the action's own branch updates), causing wasteful re-runs and near-loops.
- Preserve everything else: `environment: CI_CD`, `GITHUB_TOKEN: ${{ secrets.AUTOUPDATE_TOKEN || secrets.GITHUB_TOKEN }}`, `PR_FILTER: "all"`, `permissions`, and the `concurrency` group (for `pull_request` events `github.ref` is `refs/pull/N/merge`, so each PR gets its own group — no cross-cancellation; fine as-is).
- Same-repo branches only (no forks), so the `CI_CD` environment secret remains available on `pull_request` events.
## Definition of done
This is a workflow file — no app-level unit/E2E test applies. DoD: **valid YAML + correct trigger**, and the PR's own CI (Debug build / Unit tests / CI passed) green. Validated post-merge by observing the workflow fire on the next opened PR and update behind PRs.
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.
Problem
.github/workflows/autoupdate.ymlonly triggers onpushto main. So a PR opened during a quiet period (no subsequent merge to main) is never auto-updated and sits behindmainuntil the next merge — or a manual "Update branch" click. Observed with #256 (lane 4), which opened after the last merge and had to be updated by hand.(Note: branch protection is
strict: false, so a behind PR still merges once its checks pass — this isn't a merge blocker, but auto-updating a fresh PR means its CI runs against the latestmainimmediately, catching integration breaks sooner.)Fix
Add a
pull_requesttrigger alongside the existingpush:opened(the #256 case),reopened,ready_for_review(draft → ready while behind).synchronize— it fires on every commit push (including the action's own branch updates), causing wasteful re-runs and near-loops.environment: CI_CD,GITHUB_TOKEN: ${{ secrets.AUTOUPDATE_TOKEN || secrets.GITHUB_TOKEN }},PR_FILTER: "all",permissions, and theconcurrencygroup (forpull_requesteventsgithub.refisrefs/pull/N/merge, so each PR gets its own group — no cross-cancellation; fine as-is).CI_CDenvironment secret remains available onpull_requestevents.Definition of done
This is a workflow file — no app-level unit/E2E test applies. DoD: valid YAML + correct trigger, and the PR's own CI (Debug build / Unit tests / CI passed) green. Validated post-merge by observing the workflow fire on the next opened PR and update behind PRs.