Skip to content

workflows: use dynamic parallelism for CI#566

Merged
jmr merged 1 commit intogoogle:masterfrom
jmr:par
Apr 17, 2026
Merged

workflows: use dynamic parallelism for CI#566
jmr merged 1 commit intogoogle:masterfrom
jmr:par

Conversation

@jmr
Copy link
Copy Markdown
Member

@jmr jmr commented Apr 17, 2026

Replace hardcoded parallel job counts with dynamic CPU detection across CMake, CTest, and Bazel. This prevents resource exhaustion and "missing executable" linking failures on runners with fewer than 45 cores (notably macOS Intel runners).

  • Replace --parallel 45 with --parallel in CMake build steps.
  • Remove CTEST_PARALLEL_LEVEL: 45 to allow CTest to scale automatically based on the build's parallel settings.
  • Remove --jobs=45 from the Bazel test command to let Bazel auto-detect the runner's CPU count.

@jmr jmr force-pushed the par branch 2 times, most recently from ca023bd to 44f1ada Compare April 17, 2026 12:13
Improve parallelism in CI by dynamically determining the core count
with `getconf`. This replaces hardcoded job limits and allows the
builds to adapt to the runner size. Additionally, switch to calling
ctest directly, which is simpler.

- Add a "Set NUM_CORES" step in the CMake job using `getconf` and
  print the detected core count to the workflow output.
- Use `${{ env.NUM_CORES }}` for CMake build parallelism.
- Run tests using `ctest --parallel ${{ env.NUM_CORES }}` directly
  instead of `cmake --build . --target=test`.
- Remove explicit job counts from Bazel, allowing it to use its
  native auto-detection.
@jmr jmr merged commit a4f0cf5 into google:master Apr 17, 2026
9 checks passed
@jmr jmr deleted the par branch April 17, 2026 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant