Restrict trigger push branch for GitHub Workflow

[apupier]

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.

[sebbASF]

Whilst I agree that it would be good to restrict the workflows. it seems to me that this approach is somewhat fragile, in that it depends on enumerating the branches where the check should always run.

The names of these branches can change, and it would be easy to overlook the need to update the workflow when renaming a branch or adding a new branch that must have push checks.

Also, when a branch associated with a PR is updated, surely one wants to run the checks again?

[apupier]

Whilst I agree that it would be good to restrict the workflows. it seems to me that this approach is somewhat fragile, in that it depends on enumerating the branches where the check should always run.
The names of these branches can change, and it would be easy to overlook the need to update the workflow when renaming a branch or adding a new branch that must have push checks.

Given that it seems usually the branches are creating on branches of the contributors for this repo, we can also configure to ignore dependabot branches. it will cover most of the cases.

Also, when a branch associated with a PR is updated, surely one wants to run the checks again?

In this case, the checks are run again for the PR due to the pull_request event

[apupier]

let me update the PR to use branches-ignore

[sebbASF]

This would certainly help, as dependabot causes most of the builds.
However ideally workflows should only run once when a change is made to a branch that is part of a PR.
[I'm surprised that GH does not make this easy, as it could reduce their load considerably]

[apupier]

However ideally workflows should only run once when a change is made to a branch that is part of a PR.
[I'm surprised that GH does not make this easy, as it could reduce their load considerably]

Totally agree!

[sebbASF]

Thanks - let's see how this works out