actions: run build-gluon for all master* branches #2997
Conversation
This means the build-gluon workflow will also run automatically for master-updates branches. This allows getting a workflow run inside the own fork on GitHub without having to patch this, opening a PR towards the own Repo or the upstream repo and eating into the limited concurrent worker limit there.
|
In my opinion, matching on temporary branch names is a bit too arbitrary. |
|
I second @neocturne in this case. For build-testing on all targets, using manually triggered workflows sound like the saner approach - see https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow |
|
While i agree that it's not a clean solution, i also think that the extra step to trigger an workflow is an unneceary burden and i don't really see a diffrence to |
|
@herbetom Please keep the intention of these patterns in mind. v20* denotes all release branches, actually we can reduce the scope of these (Will open a PR). For next, I'm actually not sure why we allow arbitrary suffixes. I'll also fix that. |
In freifunk-gluon#2997 it was pointed out the current branch-trigger matches more branches than the release-branches. Retrict the match-pattern to only cover release-branches Also only trigger builds on the next-branch and not branches prefixed with this name. Link: freifunk-gluon#2997 (comment) Signed-off-by: David Bauer <[email protected]>
|
I've just remembered why the next-branch also matches on prefixed branches - THis was to support building of next-release branches. Possibly, we were not yet as experienced with working with actions - This change could have been done in the next branch itself. Possibly we could also remove the match on next from the master-branch itself. For the release branches, I see sense in keeping the pattern, as we will keep forking them from master in the future. |
|
I don't think we should include wildcards at all. We often have temporary branches that happen to match on the |
|
Closed by #3030 |
In freifunk-gluon#2997 it was pointed out the current branch-trigger matches more branches than the release-branches. Retrict the match-pattern to only cover release-branches Also only trigger builds on the next-branch and not branches prefixed with this name. Link: freifunk-gluon#2997 (comment) Signed-off-by: David Bauer <[email protected]> (cherry picked from commit b590487) Signed-off-by: Tom Herbers <[email protected]>
In freifunk-gluon#2997 it was pointed out the current branch-trigger matches more branches than the release-branches. Retrict the match-pattern to only cover release-branches Also only trigger builds on the next-branch and not branches prefixed with this name. Link: freifunk-gluon#2997 (comment) Signed-off-by: David Bauer <[email protected]>
This means the build-gluon workflow will also run automatically for master-updates branches.
This allows getting a workflow run inside the own fork on GitHub without having to patch this, opening a PR towards the own Repo or the upstream repo and eating into the limited concurrent worker limit there.