Thomas Monjalon <tho...@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 <tho...@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 <jso...@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.
