[PATCH 0/1] ci: restrict concurrency

[PATCH 0/1] ci: restrict concurrency

[Josh Soref]

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.

Josh Soref (1):
  ci: restrict concurrency

 .github/workflows/build.yml | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.32.0 (Apple Git-132)

[PATCH 1/1] ci: restrict concurrency

[Josh Soref]

Signed-off-by: Josh Soref <jsoref@gmail.com>
---
 .github/workflows/build.yml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 6cf997d6..a171d430 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -12,6 +12,9 @@ defaults:
 jobs:
   build:
     name: ${{ join(matrix.config.*, '-') }}
+    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
     runs-on: ${{ matrix.config.os }}
     env:
       AARCH64: ${{ matrix.config.cross == 'aarch64' }}
-- 
2.32.0 (Apple Git-132)

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

[Thomas Monjalon]

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?

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

[Josh Soref]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

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.

>

[-- Attachment #2: Type: text/html, Size: 1701 bytes --]

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

[Thomas Monjalon]

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.

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

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

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.

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

[Thomas Monjalon]

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?

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

[David Marchand]

On Thu, Feb 3, 2022 at 10:44 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 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.

You can manually (in the GHA webui) interrupt an older build if you
pushed to a same branch.

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

I prefer the current behavior too.
Marking patch as rejected.


-- 
David Marchand