Restrict CI push triggers to main and release branches - #6837
Conversation
Previously, the CI workflow triggered on all pushes (`[push, pull_request]`). When maintainers push feature branches directly to the upstream repository and open a pull request, GitHub Actions triggers two concurrent workflow runs for every commit, doubling CI runner consumption. This restricts the `push` event to `main` and `"v*.*"`, matching `.github/workflows/assets.yml`: - PRs continue to trigger CI via `pull_request` (exactly once per update). - Direct pushes and merges to `main` or release maintenance branches continue to run full CI. - Pushing feature branches to the repository no longer duplicates CI runs.
|
I looked into this in the past and there's an open discussion here as well: https://github.com/orgs/community/discussions/26276 The problem with this approach is that it prevents CI from running on custom branches, for example when I directly push to 1.8 I still want CI to run, so this is not the way to go. Since it only affects maintainers, I learned to ignore it. |
We can configure any branch pattern. The config I'm proposing here would run on pushes to |
|
Right, bad example on my side. I also want it to run on any other branch without me having to open a pull request 😅 |
Got it. Closing as it is working as intended. |
Previously, the CI workflow triggered on all pushes (
[push, pull_request]). When maintainers push feature branches directly to the upstream repository and open a pull request, GitHub Actions triggers two concurrent workflow runs for every commit, doubling CI runner consumption.This restricts the
pushevent tomainand"v*.*", matching.github/workflows/assets.yml:pull_request(exactly once per update).mainor release maintenance branches continue to run full CI.Addresses #6834 (comment)