Re: ci: Follow-up CI patches

Hi,

I've pushed the previous patches I had posted to 19 and master. I also have
an LLM translated set of patches for CI for 15-18 that needs some more
polish...

On 2026-11-05 17:22:36 +0300, Nazir Bilal Yavuz wrote:
> Here are two more follow-up patches; the other patches are unchanged.

Can you rebase them over what's now been merged?

> Different methods are tested with cold and warm compiler caches on a
> four-core GitHub-hosted runner. Total CompilerWarnings job times are:
>
> Cold Warm
> Default 20m 56s 3m 57s
> Parallel configure, sequential builds 19m 47s 3m 04s
> Pairs of checks, ninja -j 2 18m 10s 3m 49s
> All checks in parallel, ninja -j 1 15m 26s 2m 30s
> All checks in parallel, default ninja jobs 17m 03s 3m 48s

I think the gains of "All checks in parallel, ninja -j 1" are large enough to
make this worthwhile pursuing?

> Subject: [PATCH v15 7/8] ci: Upgrade GitHub Actions' runner OS versions
>
> Use Ubuntu 26.04, macOS 26, and Windows Server 2025 as runner operating
> sytems.
>
> Update the MacPorts version to one providing a macOS 26 installer.
> Locate Visual Studio with vswhere instead of assuming the installation
> path, as new versions might provide different Visual Studio versions
> (2026 in this case).

Might be worth breaking out the vswhere stuff might best be broken out into
its own commit?

> Subject: [PATCH v15 8/8] ci: Run compiler warning checks in parallel
>
> Use a GitHub Actions parallel step group for the CompilerWarnings job.
> + PARALLEL_CHECKS: 7
> +
> steps:
> - *nix_sysinfo_step
> - *checkout_step
> - *ccache_restore_default_step
> - *ccache_restore_branch_step
>
> + # Share the runner's CPUs between the seven parallel builds below,
> + # rather than letting each ninja invocation use all of them.
> + - name: Set build concurrency
> run: |
> + jobs=$(( $(nproc) / $PARALLEL_CHECKS ))
> + if [ "$jobs" -lt 1 ]; then jobs=1; fi
> + echo "Ninja jobs per build: $jobs"
> + echo "NINJA_JOBS=$jobs" >> "$GITHUB_ENV"
> +
> + # Each check needs its own build directory. The parallel group waits
> + # for all checks before the cache is saved and failure logs uploaded.
> + # Update PARALLEL_CHECKS when adding or removing a check.

Kinda annoying to have to maintain PARALLEL_CHECKS that way, but I can't
immediately come up with a better way.

Thanks,

Andres Freund