Re: [PATCH] ci: avoid building from the same commit in parallel

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 22, 2023, 15:31 UTC
Message-ID: <xmqqjztnm6v0.fsf@gitster.g>
In-Reply-To: <99e19de6-c17d-e85f-dc58-1019aed1e2b1@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Right, we'd need that `concurrency: ${{ github.sha }}` attribute on the
> `config` job.

That was my first thought, but I am not sure how it would work.

Doesn't skip-if-redundant grab the workflow runs that have succeeded and then see if one for the same commit already exists? If you used concurrency on the 'config', what gets serialized between two jobs for the same commit is only the 'config' phase, so 'master' may wait starting (because 'config' is what everybody else 'needs' it) while 'config' phase of 'main' runs, and then when it gets to the turn of 'config' phase of 'master', it would not find the run for the same commit being done for 'main' completed yet, would it?

> BTW there is another caveat. According to the documentation, if a job is
> queued while another job is already queued, that other job is canceled in
> favor of the latest one.

Yes, that was the impression I got; your second one will wait (so you need a working skip-if-redundant to turn it into noop), but the third and subsequent ones are discarded without starting, which unfortunately is what we may want to see happen.

Hmph, from that point of view, would the best and simplest we can do be to use the commit object name as the concurrency key for the 'config' phase, and use something similar to cancel-in-progress (which kills the other one when the new one starts, but what we want is what stops the new one to start when it notices there is already one running)?