ci: run CI on every pull request, whatever its base branch - #552
Open
RonenMars wants to merge 1 commit into
Open
ci: run CI on every pull request, whatever its base branch#552RonenMars wants to merge 1 commit into
RonenMars wants to merge 1 commit into
Conversation
`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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pull_request.branchesfilters 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_requestentirely. Every pull request runs CI, whatever its base.pushstays filtered tomainandintegration/**— that filter is a real cost control, keeping branch pushes from duplicating the run a PR already performs.Consequences worth naming
pull_request, notpull_request_target, so a fork's run gets a read-only token and no secrets.Verified state
The workflow parses to
pull_request: null, which is the GitHub Actions form for "all activity types, any base".push.branchesis 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 amain-based branch.