Re: [PATCH 2/2] ci: match Linux jobs to available CPUs

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 24, 2026, 06:13 UTC
Message-ID: <arS_nA3g-on2RdIL@pks.im>
In-Reply-To: <20260923-ci-large-test-resources-v1-2-c28416d59475@gmail.com>

On Wed, Sep 23, 2026 at 01:13:29PM -0400, Tamir Duberstein wrote:

> GitHub Actions runs ten Make test suites concurrently even on private
> Linux runners with two CPUs. Pull request runs enable the long tests.
> These runs hit ENOSPC while multiple multi-gigabyte clone and repack
> fixtures were active.

Again, a link would be appreciated that demonstrates this.

> Use nproc to choose Make and prove parallelism, as the GitLab CI path
> already does. This reduces overlapping fixtures on small Linux runners
> while keeping the long tests enabled.

It may avoid overlapping fixtures. But what does CI runtime look like before and after this change? Does it improve? Does it regress? Would it maybe make sense to oversubscribe at least a bit?

Show 12 quoted lines

> diff --git a/ci/lib.sh b/ci/lib.sh
> index c6ccbf8c17..0855026dad 100755
> --- a/ci/lib.sh
> +++ b/ci/lib.sh
> @@ -228,6 +228,10 @@ then
>  
>  	GIT_TEST_OPTS="--github-workflow-markup"
>  	JOBS=10
> +	if test linux = "$CI_OS_NAME"
> +	then
> +		JOBS=$(nproc)
> +	fi

Makes me wonder whether we should have the same logic on both GitLab and GitHub going forward. There probably isn't a good reason why these two should differ from one another.

Patrick