Hi Taylor, On Mon, 7 Nov 2022, Taylor Blau wrote: > I'm more concerned with the expense of running a job which counts > double-digit minutes against your available Actions runtime. Me, too. The fact that we used up 50.000 build minutes before we were able to finalize v2.38.1 is quite concerning. > I played around with the following, but I can't quite get Actions to > like it. The error message I get (ref[1]) is something like: > > The workflow is not valid. .github/workflows/main.yml (Line: 96, Col: > 27): Unexpected value 'needs.ci-config.outputs.skip_concurrent == 'yes'' > .github/workflows/main.yml (Line: 123, Col: 27): Unexpected value > 'needs.ci-config.outputs.skip_concurrent == 'yes'' The reason is that what you are trying to do simply cannot work. The `concurrency` setting is evaluated _before_ running the build. Yet you want to make it contingent on the output of a job that only runs _as part_ of the build. Catch-22. Reading through the thread, my assessment is that the original patch is still the best we can do. I also want to point out that the strategy described by Ævar to push every hour and see a "breadcrumb trail" of green builds is quite wasteful. Just because somebody else pays for it does not mean that it is free of cost. It very much looks like wasting resources unnecessarily to me, and I do not condone this, and I believe that the Git project should neither encourage nor support this. If you _must_ have concurrent builds of your branch (i.e. if you want to use that many resources despite the planet literally burning already from wasteful use of resources), you can always start your branch with a patch that comments out the `cancel-in-progress` line, without forcing the complexity of a more generic support for this behavior into Git's code base. Ciao, Dscho
