Re: [PATCH] ci: avoid unnecessary builds
- From
Jeff King <peff@peff.net>
- Date
- Nov 4, 2022, 03:20 UTC
- Message-ID
- <Y2SFGmQnx7CXtTEI@coredump.intra.peff.net>
- In-Reply-To
- <Y2R3vJf1A2KOZwA7@nand.local>
On Thu, Nov 03, 2022 at 10:23:56PM -0400, Taylor Blau wrote:
Show 10 quoted lines
> But I think you make a compelling point (which doesn't match my own > workflow, but I can see the utility of nonetheless). > > I was thinking that we could rely on something similar to the ci-config > ref stuff from back in e76eec35540 (ci: allow per-branch config for > GitHub Actions, 2020-05-07), but it looks like it'll be a little > trickier than that, maybe impossible. > > We need to know about the state of the ci-config branch before we set > the concurrency bits. So I think you *could* do something like:
As an aside, I wish there was a way to interpret per-repo environment variables in the actual action config. The current ci-config stuff works, but it's pretty horrible because (if I understand correctly) it spins up a VM just to evaluate a glob and say "nope, no CI needed on this branch". So:
1. It's wasteful of resources, compared to a system where the Actions
parser can evaluate a variable. 2. It makes the Actions results page for a repo ugly, because skipped
branches clutter the output with "yes, I passed CI" even though all
they passed was a trivial job to say "don't bother running more
CI". 3. The problem you mention: it happens too late to affect the overall
Actions flow, and instead individual jobs have to take it into
account.When I wrote the original ci-config stuff I looked for an alternative. You _can_ set per-repo variables in the form of secrets, but I couldn't find a way to evaluate them at the top-level of the yaml file. But maybe that has improved in the meantime. I had looked against as recently as a month or two ago and didn't find anything, but I'm far from an expert on Actions.
-Peff