Skip to content

Run CI on pull requests to any branch - #3017

Open
nohwnd wants to merge 1 commit into
mainfrom
ci-run-on-any-base-branch
Open

Run CI on pull requests to any branch#3017
nohwnd wants to merge 1 commit into
mainfrom
ci-run-on-any-base-branch

Conversation

@nohwnd

@nohwnd nohwnd commented Aug 29, 2026

Copy link
Copy Markdown
Member

Stacked pull requests do not work for development right now. A stacked pull request targets the branch below it, not main, and the branches filter on pull_request means it gets no CI at all. pester/Pester#3015 (Find the repository root from the session location, not the process working directory) sat on release-6.2.0-alpha1 and only started running checks when pester/Pester#3014 (Bump to 6.2.0-alpha1 and start docs/NEXT-RELEASE.md) merged and GitHub retargeted it to main. Until that happened there was no way to tell if the change was correct.

The filter never protected anything. With the pull_request trigger a run from a fork gets a read-only token and no secrets no matter what branch it targets, so dropping it does not change what untrusted code can reach. There is no pull_request_target anywhere in the repo, and ci.yml declares permissions: contents: read.

I also dropped paths-ignore from pull_request in ci.yml. Done is a required check on main and it lives in that workflow, so a run skipped by the filter means Done never reports and the pull request stays blocked with nothing to click. A markdown-only pull request hits this today. Runners are free for public repos, so always running is the cheaper mistake.

code-analysis.yml was narrower than ci.yml, it only ran for pull requests onto main, so rel/* and dev/* never got PSScriptAnalyzer either.

The push filters are unchanged, so this does not add runs on branch pushes.

🤖

Stacked pull requests target the branch below them, not main, and the
branches filter on pull_request meant they got no CI at all. #3015 sat on
release-6.2.0-alpha1 and only started running checks when #3014 merged and
GitHub retargeted it to main, so while working on it there was no way to
tell if the change was correct.

The filter never protected anything. With the pull_request trigger a run
from a fork gets a read-only token and no secrets no matter what branch it
targets, so dropping it does not change what untrusted code can reach. It
only ever skipped runs we wanted.

Also drop paths-ignore from pull_request in ci.yml. Done is a required
check on main and it lives in that workflow, so a run skipped by the filter
means Done never reports and the pull request stays blocked with nothing to
click. Runners are free for public repos.

code-analysis.yml was narrower than ci.yml, it only ran for pull requests
onto main, so rel/* and dev/* never got PSScriptAnalyzer either.

🤖
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