Skip to content

ci: run CI on every pull request, whatever its base branch - #552

Open
RonenMars wants to merge 1 commit into
mainfrom
ci/run-on-stacked-pr-bases
Open

ci: run CI on every pull request, whatever its base branch#552
RonenMars wants to merge 1 commit into
mainfrom
ci/run-on-stacked-pr-bases

Conversation

@RonenMars

Copy link
Copy Markdown
Owner

pull_request.branches filters on the base branch, so the only thing it can do is withhold CI from a pull request.
When no base matches, the workflow does not trigger at all: only the Snyk check reports, and GitHub shows the PR as MERGEABLE / CLEAN because nothing required is pending.

That is worse than a red build — an untested PR looks greener than a fully tested one, and nothing in the UI says CI was skipped.

It has now happened twice

The first time was task branches merging into integration/**, fixed by adding that pattern to the list. The comment recording that fix is still in the file.

The second time is #551, a stacked PR based on feat/live-activity-push-flag. feat/** was not in the list, so the same false green came back: one Snyk check, state CLEAN, and no Lint, Build, Test or Smoke had run.

Extending the list a third time only defers it. The branch in this very stack is refactor/**, so a PR based on it would be the next hole, and the failure mode gives no signal that it applied.

The change

Drop the base filter from pull_request entirely. Every pull request runs CI, whatever its base.

push stays filtered to main and integration/** — that filter is a real cost control, keeping branch pushes from duplicating the run a PR already performs.

Consequences worth naming

  • Fork PRs now run CI. Safe: this is pull_request, not pull_request_target, so a fork's run gets a read-only token and no secrets.
  • A PR to any base consumes a CI run. Intended — opening a PR is a deliberate act, and a PR without CI is the problem being fixed.

Verified state

The workflow parses to pull_request: null, which is the GitHub Actions form for "all activity types, any base". push.branches is unchanged and all seven jobs (gate, setup, warm-caches, lint, build, smoke, test) are intact.

No [skip-ci]: CLAUDE.md is explicit that workflow YAML changes still need the full matrix, and this PR is itself the check that the trigger still fires on a main-based branch.

`pull_request.branches` filters on the BASE branch, so the only thing it can do is withhold CI from a pull request.
When no base matches, the workflow does not trigger at all: only the Snyk check reports, and GitHub shows the PR as MERGEABLE/CLEAN because nothing required is pending — so an untested PR looks greener than a fully tested one.

This has now happened twice.
First for task branches merging into `integration/**`, fixed by adding that pattern; then for a stacked PR based on `feat/live-activity-push-flag` (#551), where `feat/**` was absent and the same false green came back.
Extending the list again only defers it, since a stack based on a `refactor/**` or `fix/**` branch is the next hole and the failure gives no signal that it applied.

`push` stays filtered to main and integration branches — that filter is a real cost control, keeping branch pushes from duplicating the run a PR already performs.
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