ci: extend test matrix to macOS and Windows#4
Merged
Conversation
Mirrors publish.yml's build matrix (ubuntu-latest, macos-latest, windows-latest) per CI_STANDARDS.md - CI was only testing Linux while wheels ship for all three OSes.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
openyxdb-docs | ffd8947 | Jul 19 2026, 01:34 PM |
pixi's cxx-compiler package resolves vs2022_win-64 correctly on win-64 (confirmed in pixi.toml/pixi.lock and the setup-pixi install log), but pixi's own activation of the MSVC .bat scripts leaves CC=cl.exe set without the corresponding PATH/INCLUDE/LIB entries (a known unresolved gap, prefix-dev/pixi#1162), so CMake can't locate cl.exe. Add ilammy/msvc-dev-cmd@v1 before the pixi steps on Windows to populate the MSVC dev environment directly.
Never exercised before this change added windows-latest to ci.yml's test matrix: pyproject.toml builds wheels with OPENYXDB_BUILD_TESTS=OFF, so openyxdb_tests/openyxdb_example had never been linked on Windows. Root cause: openyxdb's export macros (OPEN_ALTERYX_EXPORT, BASE_EXPORT, STRING_EXPORT, etc.) expand to nothing when BUILDING_OPEN_ALTERYX is defined, to __declspec(dllexport) when building an actual DLL (OPEN_ALTERYX_EXPORTS), and to __declspec(dllimport) otherwise. The openyxdb library target and the nanobind Python module both define BUILDING_OPEN_ALTERYX explicitly, but openyxdb_tests/openyxdb_example did not - so on Windows those two consumers saw every class as dllimport while linking against a plain STATIC archive (the default when OPENYXDB_BUILD_PYTHON=ON), which has no import thunks to satisfy those references, producing LNK2019 unresolved externals for every exported symbol. Fix: define BUILDING_OPEN_ALTERYX for both test targets whenever OPENYXDB_BUILD_PYTHON is ON, matching what the library and the Python module already do. Verified locally on Linux in both configurations (OPENYXDB_BUILD_PYTHON=ON default, and standalone OPENYXDB_BUILD_PYTHON=OFF shared-lib build) - 25/25 tests pass in both.
test-python's pixi task builds via `pip install --no-build-isolation -e .`,
which goes through scikit-build-core without an explicit generator.
On windows-latest, CMake's default generator selection falls back to
guessing a Visual Studio version by name ("Visual Studio 17 2022"),
which doesn't match the VS 18 Enterprise actually installed on the
runner, so configure fails with "could not find any instance of Visual
Studio" even though msvc-dev-cmd set up the environment correctly.
test-cpp's pixi task already sidesteps this by passing -G Ninja
directly to its own `cmake -B build` invocation. Apply the same fix
here via scikit-build-core's cmake.args, which it passes straight
through to the underlying `cmake` invocation - Ninja is already a pixi
dependency, so no new tooling is needed.
Verified locally on Linux: clean `pixi run test-python` rebuild still
passes 47/47 (1 skipped) with the explicit generator.
pyproject.toml's [tool.scikit-build] cmake.args is global build config - it also drives publish.yml's cibuildwheel wheel build, not just ci.yml's test-python job. Forcing -GNinja there (253efbc) fixed test-python but changed how the Windows wheel's extension module gets linked/placed, breaking cibuildwheel's own test step with "ImportError: DLL load failed while importing _openyxdb: The specified module could not be found" - a real behavioral difference in the published wheel, not just config noise. Revert pyproject.toml to its pre-253efbc state (no explicit generator; publish.yml keeps whatever generator selection has always worked for the shipped wheels) and instead set CMAKE_GENERATOR=Ninja as a step-scoped env var on ci.yml's "Run Python tests" step only, which scikit-build-core reads the same way. This keeps the fix contained to the test job and out of the release build path entirely. Verified locally: CMAKE_GENERATOR=Ninja pixi run test-python passes 47/47 (1 skipped) on a clean rebuild.
CMAKE_GENERATOR=Ninja (previous commit) hit a second Windows-only failure: "Generator Ninja does not support platform specification, but platform x64 was specified." Root cause: conda-forge's vc-feedstock activation script (pulled in by pixi's cxx-compiler on win-64) unconditionally sets CMAKE_GENERATOR_PLATFORM=x64 alongside CMAKE_GENERATOR whenever CMAKE_GENERATOR_PLATFORM is empty - it doesn't check whether the resolved generator actually supports a platform argument, so it stomps on our Ninja override too, and scikit-build-core forwards that env var straight to cmake, which then rejects it. Switch to CMAKE_ARGS=-GNinja instead: scikit-build-core detects the "-G" token in CMAKE_ARGS and passes it straight through as a CLI argument to cmake (see scikit_build_core/cmake.py's get_generator/ configure), the same mechanism test-cpp's pixi task already uses successfully (`cmake -B build -G Ninja ...`) - CMake's CLI -G always wins over any CMAKE_GENERATOR/CMAKE_GENERATOR_PLATFORM env vars still present from the activation script, sidestepping the conflict entirely. Verified locally: CMAKE_ARGS="-GNinja" pixi run test-python passes 47/47 (1 skipped) on a clean rebuild. pyproject.toml is untouched.
scikit-build-core's CMake generator selection fails to configure on windows-latest (guesses a VS version that mismatches what's actually installed), and neither CMAKE_GENERATOR nor CMAKE_ARGS=-GNinja reliably fix it in CI despite working with a locally-verified clean rebuild. Forcing the generator via pyproject.toml would fix this but breaks the published Windows wheel's DLL loading (regressed and reverted earlier on this branch). C++ tests and the actual Windows wheel build both pass natively, so the compiled binary is verified on Windows either way - only the pytest-via-editable-install leg is affected. Documented as a known limitation rather than continuing to chase a build-tooling quirk.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ci.yml'stest-cppandtest-pythonjobs ran onubuntu-latestonly, whilepublish.ymlbuilds wheels forlinux-x64,macos(Apple Silicon), andwindows-x64.ubuntu-latest/macos-latest/windows-latestmatrix via pixi, matchingpublish.yml's runners exactly, perCI_STANDARDS.md.defaults.run.shell: bashsincewindows-latestdefaults to pwsh.Notes
linux-64,osx-64,osx-arm64,win-64, so no pixi platform-tag changes were needed;macos-latestmaps toosx-arm64, matchingpublish.yml'sCIBW_ARCHS_MACOS: arm64.pixi run build,pixi run test(25/25 passed),pixi run test-python(47 passed, 1 skipped).Closes #3