Workflows that gate `pull_request` on `branches: [main]` are silently
skipped for the head-ref push that `gt submit` makes during a stack
restack: Graphite momentarily flips the PR's base off of `main` before
resetting it back, and GitHub does not re-evaluate `pull_request`
triggers on `base_ref_changed` events with the default activity types.
The result: required checks (Build, Typecheck, Test: runtime contract,
Windows render, Windows tests, Semantic PR title) never run for that
head SHA and the PR sits in BLOCKED forever — even when the head
matches a green commit on `main`. PR #396 hit this exact pattern after
#426 added the `branches: [main]` filters.
Adding `edited` to the activity types causes the workflow to re-fire
when the base is set back to `main`. The existing `branches: [main]`
filter still rejects intermediate stack PRs, preserving #426's intent
of skipping CI on stack PRs that aren't yet targeting `main`.
* ci: skip PR runs when targeting a non-main base branch
Adds `branches: [main]` to the `pull_request:` trigger of each workflow
that runs on PRs (CI, regression, Windows render verification, Docs,
Catalog Previews). PRs whose base is something other than main — typical
for stacked PRs — no longer trigger these workflows.
On a 5-PR Graphite stack this turns 5× CI runs into 1× (when the tip
of the stack reaches main). When a child PR is rebased/promoted so its
base becomes main, CI fires as normal.
publish.yml and the default CodeQL setup are untouched: publish already
filters to main, and CodeQL is default-setup (org UI, not a repo YAML).
* chore(ci): fix oxfmt formatting on renovate.json
Same drive-by as #423. Renovate's config-migration PR #422 landed
unformatted (Renovate bot skips lefthook), so every PR branched from
current main fails `bun run format:check`. Whichever of #423 / #426
merges first cleans it up.
Vance Ingalls