Skip to content

ci: Vary one dimension at a time from a single origin - #132

Merged
copybara-service[bot] merged 1 commit into
masterfrom
test_1017121896
Nov 9, 2026
Merged

copybara-service[bot] merged 1 commit into
masterfrom
test_1017121896

Conversation

@copybara-service

@copybara-service copybara-service Bot commented Nov 9, 2026 •

Copy link
Copy Markdown

ci: Vary one dimension at a time from a single origin

Each build workflow previously defined its own matrix, repeating compiler,
C++ standard, build-mode, and Python-version combinations across operating
systems and build systems. Even without the Intel macOS workflows, the two
remaining macOS workflows spawn 6 jobs per run against GitHub Actions'
5-concurrent-macOS-job limit, and the macOS and Windows Bazel workflows
build with -c opt, compiling most files twice (PIC and non-PIC).

Restructure the 6 build workflows around a single origin (ubuntu-26.04,
clang-22, Bazel 9.x, fastbuild, C++17, Python 3.12) in
amd64_linux_bazel and vary one dimension at a time from it, using a flat
matrix: include: list across all workflows:

  • Compiler, C++ standard, Python version, and Bazel version variations run
    only on Linux, where runners are fast and plentiful, and CMake on Linux
    varies only CMake-specific settings (version, generator, build type).
  • macOS drops from 6 jobs to 2 (1 fastbuild job in arm64_macos_bazel
    and 1 Xcode multi-config job in arm64_macos_cmake, exercising the
    APPLE target properties and Xcode generator), and Windows Bazel
    switches from opt to fastbuild (retaining windows-2022 and -c dbg
    for MSVC _DEBUG).
  • arm64_macos_cmake and amd64_windows_cmake are kept as single jobs
    even though their OSes and CMake are already tested separately, because
    our CMake config has APPLE, WIN32 (BUILD_SHARED_LIBS=ON DLL copy),
    and multi-config (Xcode / Visual Studio LIBRARY_OUTPUT_DIRECTORY)
    logic that Linux CMake and Bazel do not exercise.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please keep it to test XCode and Apple Clang

@copybara-service
copybara-service Bot force-pushed the test_1017121896 branch 3 times, most recently from 8e09340 to cc84a6c Compare November 9, 2026 14:03
Each build workflow previously defined its own matrix, repeating compiler,
C++ standard, build-mode, and Python-version combinations across operating
systems and build systems. Even without the Intel macOS workflows, the two
remaining macOS workflows spawn 6 jobs per run against GitHub Actions'
5-concurrent-macOS-job limit, and the macOS and Windows Bazel workflows
build with `-c opt`, compiling most files twice (PIC and non-PIC).

Restructure the 6 build workflows around a single origin (`ubuntu-26.04`,
`clang-22`, Bazel `9.x`, `fastbuild`, C++17, Python 3.12) in
`amd64_linux_bazel` and vary one dimension at a time from it, using a flat
`matrix: include:` list across all workflows:

* Compiler, C++ standard, Python version, and Bazel version variations run
  only on Linux, where runners are fast and plentiful, and CMake on Linux
  varies only CMake-specific settings (version, generator, build type).
* macOS drops from 6 jobs to 2 (1 `fastbuild` job in `arm64_macos_bazel`
  and 1 `Xcode` multi-config job in `arm64_macos_cmake`, exercising the
  `APPLE` target properties and Xcode generator), and Windows Bazel
  switches from `opt` to `fastbuild` (retaining `windows-2022` and `-c dbg`
  for MSVC `_DEBUG`).
* `arm64_macos_cmake` and `amd64_windows_cmake` are kept as single jobs
  even though their OSes and CMake are already tested separately, because
  our CMake config has `APPLE`, `WIN32` (`BUILD_SHARED_LIBS=ON` DLL copy),
  and multi-config (`Xcode` / Visual Studio `LIBRARY_OUTPUT_DIRECTORY`)
  logic that Linux CMake and Bazel do not exercise.

PiperOrigin-RevId: 1017290821
@copybara-service
copybara-service Bot merged commit c243b16 into master Nov 9, 2026
@copybara-service
copybara-service Bot deleted the test_1017121896 branch November 9, 2026 14:16
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.

2 participants