Skip to content

ci: run the gate on stacked pull requests - #533

Merged
emal-avala merged 1 commit into
mainfrom
fix/ci-on-stacked-prs
Jul 27, 2026
Merged

ci: run the gate on stacked pull requests#533
emal-avala merged 1 commit into
mainfrom
fix/ci-on-stacked-prs

Conversation

@emal-avala

Copy link
Copy Markdown
Member

Summary

.github/workflows/ci.yml only triggered on pull requests targeting main:

pull_request:
  branches: [main]

So a PR based on another feature branch ran nothing. Two are open right now — #531 (base feat/session-picker) and #532 (base feat/session-switching) — and neither has been compiled, linted or tested by CI.

Why this is worse than failing

$ gh pr checks 532
no checks reported on the 'feat/session-roster' branch

$ gh pr checks 532 --json name,bucket --jq '[.[]|select(.bucket=="fail")]'
[]

gh pr checks reports no failures, because there is nothing to fail. The PR page shows no red. A stacked PR is indistinguishable from a passing one in every surface that shows a green tick — including automation that gates on "no failing checks".

I hit exactly that: I reported this chain as green earlier in the session on the strength of fail:none, which was true and meaningless.

Fix

Drop the branch filter so any pull request runs the gate, whatever it targets. The push trigger keeps its main-only filter, so this does not add a run per branch push — only per PR.

The client workflows (client-ci, client-playwright, client-e2e) already have no branch filter; this brings the Rust gate in line with them.

Verified separately

feat/session-roster does pass — 785 bin tests, clippy --all-targets -- -D warnings and fmt --check clean, cargo test --workspace --all-targets green apart from the 3 bwrap_* tests that fail on this host with setting up uid map: Permission denied. That was checked locally, which is precisely the gap this PR closes: it should not have needed checking by hand.

The CI workflow only triggered on pull_request targeting main, so a PR
based on another feature branch ran nothing. Three such PRs are open now
(#531, #532) and neither has been compiled, linted or tested by CI.

That is worse than failing. `gh pr checks` reports no failures because
there is nothing to fail, and the PR page shows no red — a stacked PR
looks indistinguishable from a passing one.

Dropping the branch filter means any pull request runs the gate,
whatever it targets. The push trigger keeps its main-only filter, so
this does not add a run per branch push — only per PR.

The client workflows already had no branch filter; this brings the Rust
gate in line with them.
@emal-avala

Copy link
Copy Markdown
Member Author

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Bravo.

Reviewed commit: f87898ed15

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@emal-avala
emal-avala merged commit f7e9472 into main Jul 27, 2026
14 checks passed
@emal-avala
emal-avala deleted the fix/ci-on-stacked-prs branch July 27, 2026 23:12
@emal-avala emal-avala mentioned this pull request Jul 28, 2026
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant