From: Tamir Duberstein <tamird@gmail.com>
Date: Mon, 28 Sep 2026 10:16:33 GMT
Subject: Re: [PATCH v2 2/2] ci: align job counts across CI providers
Message-ID: <CAJ-ks9mWU2cFWLfioSSM_6Ct1ydtxn3i4Dh-L537M5EDiMW3vQ@mail.gmail.com>
In-Reply-To: <aroK7KcRabARSqd8@pks.im>

On Mon, Sep 28, 2026 at 2:36 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Fri, Sep 25, 2026 at 12:35:39PM -0400, Tamir Duberstein wrote:
> > GitHub Actions sets JOBS to ten regardless of runner size, while
> > GitLab CI uses the detected CPU count. Use the CPU count for Make and
> > prove on both providers, selecting JOBS after the operating system
> > is identified.
>
> Again, it should be noted here what the effect of this is. In other
> words, does GitHub slow down as a result? You already showed numbers
> during the discussion on v1 of this series, and these numbers should
> probably be included in this message, too.

Agreed, but in this case there was no reliable performance change
across 10 runs; I could include that.

>
> > Use nproc on Linux and NUMBER_OF_PROCESSORS on Windows. On macOS, use
> > sysctl to avoid requiring nproc before the dependency installer has run;
> > GitHub macOS images need not provide GNU coreutils.
>
> Huh... "need not" feels somewhat weird as phrasing. I guess it's rather
> "does not", and consequently we have to adapt? I think instead of
> describing what you do, I'd directly pinpoint what matters:
>
>   Note that we continue to use the same logic to detect the number of
>   processors on both Linux and Windows. But on macOS, we cannot continue
>   to use nproc(1) because the image used by GitHub does not provide that
>   tool. Use sysctl instead, which is available on both GitLab and
>   GitHub

Agreed.
.
>
> Thanks!
>
> Patrick