Restrict trigger push branch for GitHub Workflow#395
Conversation
Feature branches rarely need their own CI runs: the code is already tested when a pull request is opened against a release branch. If the push trigger has no branch restriction and pull_request is also configured, every push to a branch with an open PR runs the workflow twice: once for the push and once for the PR synchronisation. Always give the push trigger an explicit list of branches: this stops branches created from a release branch from inheriting its workflow runs. see https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=430408443#GitHubActionsRecommendedPractices-Restrictthepushtriggertospecificbranches Signed-off-by: Aurélien Pupier <apupier@ibm.com>
apupier
force-pushed
the
restrictTrigerPushForGitHubWorkflows
branch
from
de17b4a to
c843536
Compare
|
I'm going to close this PR because it would be very bad for the release process which actually does require branches get the full CI run. |
|
Which pattern is used for the branch naming of the release process? We can configure to continue to build them. I'm unable to find a specific branch for releases. Last release was on 4th March but I see no build https://github.com/apache/yetus/actions?page=17 Another alternatives is to use branches-ignore for dependabot branches which is the case which is triggerring the build two times for the exact same commit the most often. (maybe always for this repository as it seems that the branches are always created out of forked repo) |
|
You should probably start by reading the documentation and actually understanding what this project is about before filing this type of PR. I'm also aware you did the same thing with quite a few other projects. |
2 participants
Feature branches rarely need their own CI runs: the code is already tested when a pull request is opened against a release branch. If the push trigger has no branch restriction and pull_request is also configured, every push to a branch with an open PR runs the workflow twice: once for the push and once for the PR synchronisation.
Always give the push trigger an explicit list of branches: this stops branches created from a release branch from inheriting its workflow runs.
see https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=430408443#GitHubActionsRecommendedPractices-Restrictthepushtriggertospecificbranches