Skip to content

Commit 8869a30

Browse files
cristianocclaude
andcommitted
Say what a stacked PR needs for CI to run
The stacked-PR guidance told you to verify that CI runs for every PR but named nothing that makes it fail, so a stack that goes dark leaves you guessing. Record the mechanism: `gh stack link` moves each base onto the branch below, and both triggers in ci.yml filter on `master` and `11.0_release`, which for `pull_request` matches the base. Also record what is safe to do about it, since the obvious worry is wasted CI: results attach to the head SHA and survive a later base change, and re-linking mid-run cancels nothing, so there is no reason to wait for CI before linking a stack. Signed-off-by: Cristiano Calcagno <ccrisccris@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W8g8qwBARAcvW9MyuKQq8H
1 parent 0240fbf commit 8869a30

1 file changed

Lines changed: 14 additions & 0 deletions

File tree

AGENTS.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -298,6 +298,20 @@ branches linear and in the same repository, and list branches or PRs from
298298
bottom to top. For existing PRs, use `gh stack link BOTTOM_PR [NEXT_PR...]`,
299299
then verify that GitHub reports stack metadata and runs CI for every PR.
300300

301+
`gh stack link` rewrites each PR's base to the branch below it; only the bottom
302+
PR keeps `master`. That matters because CI keys off the base: both triggers in
303+
`.github/workflows/ci.yml` are filtered to `branches: [master, 11.0_release]`,
304+
and for `pull_request` that filter matches the *base* branch, with no `push`
305+
fallback for feature branches. So "verify CI runs for every PR" means watching
306+
a real push produce check runs on each one, not just reading the stack UI.
307+
308+
If a PR in the stack goes dark, retarget it with `gh pr edit <n> --base master`,
309+
push, let CI finish, then re-link. Two properties make that safe, both observed:
310+
check runs attach to the head SHA, so completed results survive a later base
311+
change; and re-linking mid-run neither cancels in-flight runs nor starts new
312+
ones, because a base change is not one of the `pull_request` types the workflow
313+
listens for. There is no need to wait for CI before re-linking.
314+
301315
### Code Quality
302316

303317
- Follow existing patterns in the codebase

0 commit comments

Comments
 (0)