On Wed, Sep 13, 2023 at 04:16:48PM +0100, Phillip Wood wrote: > On 11/09/2023 10:36, Jeff King wrote: > > On Thu, Sep 07, 2023 at 11:04:33AM +0100, Phillip Wood wrote: > > Looking at the ci-config branch of phillipwood/git.git, I see this in > > your allow-refs: > > > > refs/heads/main|refs/heads/master|refs/heads/maint|refs/heads/next|refs/heads/seen|refs/tags/gitgui-*|refs/tags/pr-[0-9]*|refs/tags/v[1-9].*) > > > > So you do use multiple prefixes, though all in refs/tags/. Do you > > actually push tags for which you do want to run CI, > > Yes, but not very often - I could probably just reject all tags and start > the CI manually when I want it (assuming that's an option). Thanks for > digging into the various options, it sounds like it is possible so long as > we don't want multiple prefixes. I'll additionally have to switch to using the full refname in the matches, but that is probably a reasonable thing to do anyway (it makes config a bit more verbose, but it is obviously much more flexible). We can do the loop-unroll thing if we really want to support multiple prefixes, but if you're OK with it, let's try the single-prefix way and see if anybody runs into problems (I'm still convinced there's only a few of us using this stuff anyway). I'm hesitant to do the unroll just because it requires picking a maximum value, with a bizarre failure if you happen to have 4 prefixes or whatever. I'll see if I can polish up what I showed earlier into a patch. (BTW, one other thing I tried was using fromJSON(vars.CI_CONFIG) in the "on" expression, which in theory would allow globbing. But it doesn't look like expressions work at all in that context. And even if they did, I'm not sure we could make it work such that an empty CI_CONFIG used some defaults, since there's no conditional-expression ternary operator). > Aside: what I'd really like is to be able to set an environment variable > when I push to skip or force the CI > > GITHUB_SKIP_CI=1 git push github ... > > but that would require support from the git client, the protocol and the > server. We have the necessary bits at the protocol: push-options. But it's up to the server-side hooks to decide which ones are meaningful and to do something useful with them. It looks like GitLab supports: git push -o ci.skip=1 ... but I don't think GitHub respects any equivalent option. -Peff
