Skip to content

Restrict trigger push branch for GitHub Workflow#414

Open
apupier wants to merge 1 commit into
apache:masterfrom
apupier:configureTriggerPsuhForGitHubWorkflows
Open

Restrict trigger push branch for GitHub Workflow#414
apupier wants to merge 1 commit into
apache:masterfrom
apupier:configureTriggerPsuhForGitHubWorkflows

Conversation

@apupier

@apupier apupier commented Jul 2, 2026

Copy link
Copy Markdown

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

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

  • Read the contribution guidelines for this project.
  • Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
  • I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
  • Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

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

apupier commented Jul 2, 2026

Copy link
Copy Markdown
Author

build error on CI check is unrelated to this PR:

[79](https://github.com/apache/commons-jcs/actions/runs/28573288833/job/84715788817#step:5:780)
Error:  Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.12.0:javadoc (default-cli) on project commons-jcs4-jcache: An error has occurred in Javadoc report generation: Project contains Javadoc Warnings -> [Help 1]

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