Re: [PATCH 1/1] ci: restrict concurrency

[Aaron Conole <aconole@redhat.com>]

Thomas Monjalon <thomas@monjalon.net> writes:

> Aaron, David,
> Please could you review this patch?
> Thanks
>
> 13/01/2022 13:41, Josh Soref:
>> On Thu, Jan 13, 2022, 6:42 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>> 
>> > Hi,
>> >
>> > The explanation should be in the patch, not the cover letter.
>> > Actually, you don't need a cover letter for a single patch.
>> > Copying it here:
>> > "
>> > dpdk is fairly expensive to build in GitHub.
>> >
>> > It's helpful to abandon old builds as soon as there's a new
>> > build waiting instead of wasting resources on the previous
>> > round.
>> > "
>> >
>> > 12/01/2022 07:50, Josh Soref:
>> > > Signed-off-by: Josh Soref <jsoref@gmail.com>
>> > > ---
>> > > +    concurrency:
>> > > +      group: build-${{ matrix.config.os }}-${{ matrix.config.compiler
>> > }}-${{ matrix.config.library }}-${{ matrix.config.cross }}-${{
>> > matrix.config.mini }}-${{ github.event.pull_request.number || github.ref }}
>> > > +      cancel-in-progress: true
>> >
>> > The goal of the CI is to catch any issue in a submitted patch.
>> > Is your change cancelling a test of a patch when another one is submitted?
>> >
>> 
>> If it's on the same branch or if it's in the same pull request yes,
>> otherwise, no.

We currently have a report on every patch, which helps us when a patch
series has a breaking failure in the middle and then fixes it in a later
patch.  With the mechanism you have here, we lose that ability - it is
important to have, as a `git bisect` can be broken without this feature.

How much of a problem is this in practice?  I want us to be good
citizens, but also I don't want to lose the bisect-ability of the
series.