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