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

[Thomas Monjalon <thomas@monjalon.net>]

03/02/2022 21:21, Aaron Conole:
> 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.

Good point.

> 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.

Bisectability is important.

So we have to reject this patch, right? Or any other idea?