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
