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

[gemmellr]

Personally I use CI runs on [fork] feature branches regularly so I'll find this rather annoying, though it can be worked around with the manual trigger (or some [ab]use of branch name conventions). I think its good to test things on forks before using the foundations shared resources with a run on a PR. If I need to update a PR I'll often tend to do it on a different fork branch before finally updating the PR branch when ready, though obviously that causes an extra fork run, and I know the same doesnt apply to everyone.

Cant read the wiki link currently as jira/confluence login is broken just now.

[apupier]

Cant read the wiki link currently as jira/confluence login is broken just now.

I copy-pasted the pointed chapter in the description, there isn't more information

Personally I use CI runs on [fork] feature branches regularly so I'll find this rather annoying, though it can be worked around with the manual trigger (or some [ab]use of branch name conventions). I think its good to test things on forks before using the foundations shared resources with a run on a PR. If I need to update a PR I'll often tend to do it on a different fork branch before finally updating the PR branch when ready, though obviously that causes an extra fork run, and I know the same doesnt apply to everyone.

Would it be suitable to provide another branch name for the ones you want to have workflow executed on your fork?

Otherwise, given that it doesn't seem that branches are created by committers directly on the Apache Artemis repo, the most often branches that are triggering the duplicated calls are the dependabot branches. So we could configure branches-ignore instead. We want for this solution on another repo apache/nifi#11376

[gemmellr]

Cant read the wiki link currently as jira/confluence login is broken just now.

I copy-pasted the pointed chapter in the description, there isn't more information

Personally I use CI runs on [fork] feature branches regularly so I'll find this rather annoying, though it can be worked around with the manual trigger (or some [ab]use of branch name conventions). I think its good to test things on forks before using the foundations shared resources with a run on a PR. If I need to update a PR I'll often tend to do it on a different fork branch before finally updating the PR branch when ready, though obviously that causes an extra fork run, and I know the same doesnt apply to everyone.

Would it be suitable to provide another branch name for the ones you want to have workflow executed on your fork?

Thats what I meant by "(or some [ab]use of branch name conventions)." yep, though it would still be a little annoying.

Otherwise, given that it doesn't seem that branches are created by committers directly on the Apache Artemis repo, the most often branches that are triggering the duplicated calls are the dependabot branches. So we could configure branches-ignore instead. We want for this solution on another repo apache/nifi#11376

Yep we dont use feature branches in the main repo, so I think the branches-ignore route to suppress duplicate runs for dependabot pushes might make the most sense here too. I always disliked that it doesnt use a fork, this is another reason to.

[gemmellr]

LGTM but lets give others some time to comment.

[clebertsuconic]

LGTM