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

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

LLMs, Commit messages and PR description:

• Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.
• LLM assisted commits should be attributed with an Assisted-by: MODEL_NAME MODEL_VERSION line appended to the commit message.
  • Please mention coding assistance in the PR description too (eg. by adding the same Assisted-by line from above)
  • Please describe the changes in your own words - we'd like to know you understand the changes being made!

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[neilcsmith-net]

Thanks @apupier Anything particular trigger this PR, or just analysis of repos? It's a small and not often triggered workflow. Matches configuration already set in other workflows.

Looked like this got left out of #6710 @mbien any reason for that?

Labelled and retriggered to pass paperwork tests.

[mbien]

Looked like this got left out of #6710 @mbien any reason for that?

probably no reason. I might have either overlooked the workflow file or looked at the trigger list and determined that it won't run anyway since nobody changes anything on those paths.

But its good to add branch filters to the workflow for symmetry reasons alone.

[apupier]

Anything particular trigger this PR, or just analysis of repos?

i launched an analysis of all Apache repos to try to reduce the workload on the shared pool of GitHub runners for Apache org. You can see (imperfect) result here https://github.com/apupier/github-actions-scanner/blob/main/reports/ranked-push-impact.txt .

In recent weeks, it happened regularly that jobs are queued due to all GitHub runners being busy.

I have not analyzed if this specific GitHub workflows is really taking a lot of time, only analyzed the workflow definition.