Jeff King <peff@xxxxxxxx> writes: > But that is missing the point of the exercise, no? The question of what > gitster/git should do was a side conversation. The purpose of Dscho's > original patch and Danh's followup was to allow anybody to choose which > branches in their own fork. I.e.: > >> * Actions is running on all branches, of all forks, all the time. > > This is how it works now, and is the exact thing we are trying to fix. Thanks for clarifying and refocusing the discussion. I am onboard. It seems to me that there are only two and half approaches, then: - Branch-build is opt-in; only branches that match selected, known, and fixed patterns will be built (e.g. 'maint', 'maint-*', 'master', 'next', 'pu', and 'for-ci/*'). - Branch-build is opt-out; branches that match selected, known, and fixed patterns will be excluded (e.g., '*-wip'). - If you do not want your branches want to be skipped, you need to tweak the commit at the tip (e.g. mark with '[skip ci]' log message, munging .github/workflows/ in the tree). The last one is only there for completeness. I do not think mucking with the objects recorded in the history, whether it is a tweaked log message or tweaked tree contents, is a good way to do this. More random ideas... Would it be too much hassle to use notes for a thing like this? Perhaps push out with refs/notes/skip-ci note attached to a commit you do not want to be built? I have a feeling that it gives way overkill flexibility with little gain (probably too cumbersome to manage). Does push into GitHub repository offer an ability to pass arbitrary push option, to which actions that trigger "on: push" event can react?
