Re: [PATCH v2 1/2] CI: limit GitHub Actions to designated branches

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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?