ROS 2 Windows CI on GitHub Actions: current options and a Pixi-based pattern

<p>I’m trying to understand what we should currently recommend for ROS 2 projects that want to run a real Windows CI job on GitHub Actions, including both build and tests.</p> <p>There are several existing actions and examples, but their Windows behavior is somewhat different from Linux. I recently compared a few approaches with ROS 2 Lyrical in a small <a href="https://github.com/dskkato/ros2_rmw_launch_smoke_test" rel="noopener nofollow ugc">AI-assisted smoke-test repository</a>, and thought it might be useful to summarize what I found and ask whether there is already a preferred approach.</p> <h2><a class="anchor" href="https://discourse.openrobotics.org#p-117379-what-i-found-1" name="p-117379-what-i-found-1"></a>What I found</h2> <h3><a class="anchor" href="https://discourse.openrobotics.org#p-117379-action-ros-ci-2" name="p-117379-action-ros-ci-2"></a><code>action-ros-ci</code></h3> <p><a href="https://github.com/ros-tooling/action-ros-ci/blob/v0.4/src/action-ros-ci.ts#L280-L325" rel="noopener nofollow ugc"><code>action-ros-ci@v0.4</code></a> currently has:</p> <pre><code class="lang-auto">const doTests = !isWindows; </code></pre> <p>so <code>colcon test</code> is intentionally skipped on Windows. The related background seems to be <a href="https://github.com/ros-tooling/action-ros-ci/pull/712" rel="noopener nofollow ugc">ros-tooling/action-ros-ci#712</a>.</p> <p>This makes it useful for some Windows build jobs, but not for CI whose purpose is explicitly to verify tests.</p> <h3><a class="anchor" href="https://discourse.openrobotics.org#p-117379-setup-ros-3" name="p-117379-setup-ros-3"></a><code>setup-ros</code></h3> <p>I also tried <a href="https://github.com/ros-tooling/setup-ros" rel="noopener nofollow ugc"><code>setup-ros@v0.7</code></a> with Lyrical.</p> <p>In <a href="https://github.com/dskkato/ros2_rmw_launch_smoke_test/actions/runs/33240774199/job/99069638775?pr=3" rel="noopener nofollow ugc">this experiment</a>, it selected the April 30 Lyrical beta binary and ended up combining the GitHub-hosted Python 3.12 environment with an older colcon/Python toolchain.</p> <p>That caused plugin-loading errors involving removed Python APIs such as <code>pkgutil.ImpImporter</code> and <code>distutils</code>. More importantly, the job still completed successfully with effectively:</p> <pre><code class="lang-auto">Summary: 0 packages finished ... Summary: 0 tests, 0 errors, 0 failures, 0 skipped </code></pre> <p>This may be specific to this Lyrical configuration, and I may be missing an intended version pin or setup. However, the false-green result seems worth being aware of.</p> <h3><a class="anchor" href="https://discourse.openrobotics.org#p-117379-pinned-ros-2-binary-pixi-4" name="p-117379-pinned-ros-2-binary-pixi-4"></a>Pinned ROS 2 binary + Pixi</h3> <p>The approach that worked most consistently in my experiment was:</p> <ol> <li> <p>Download a known ROS 2 Windows binary release.</p> </li> <li> <p>Use the <code>pixi.toml</code> provided with the ROS 2 source/release environment.</p> </li> <li> <p>Run <code>pixi install</code>.and <code>preinstall_setup_windows.py</code>.</p> </li> <li> <p>Enter the Visual Studio developer environment and source ROS 2.</p> </li> <li> <p>Run <code>colcon build</code>, <code>colcon test</code>, and <code>colcon test-result</code> explicitly.</p> </li> </ol> <p>For example, <a href="https://github.com/dskkato/ros2_rmw_launch_smoke_test/blob/0e4eedb78a1b9253e454e7a719df6fc85d7b6925/.github/workflows/launch-test.yml" rel="noopener nofollow ugc">this workflow</a> uses the <a href="https://github.com/ros2/ros2/releases/tag/release-lyrical-20260807" rel="noopener nofollow ugc">2026-08-07 Lyrical Windows binary</a> and successfully runs launch tests against Fast DDS, Cyclone DDS, and Zenoh.</p> <p>There are also existing Windows CI examples with a similar shape:</p> <ul> <li> <p><a href="https://github.com/ros2-rust/ros2_rust/blob/4606ed41a212fb6c65ab01d1e79ddabde4e7cb05/.github/workflows/rust-win.yml" rel="noopener nofollow ugc"><code>ros2-rust</code></a> uses Pixi around a ROS 2 Rolling binary environment.</p> </li> <li> <p><a href="https://github.com/ros-controls/ros2_control_ci/blob/master/.github/workflows/reusable-ros-tooling-win-build.yml" rel="noopener nofollow ugc"><code>ros-controls/ros2_control_ci</code></a> also has a reusable Pixi-based Windows workflow using a Rolling binary underlay.</p> </li> </ul> <p>They are not exactly equivalent use cases—the ros-controls workflow, for example, is primarily a build workflow—but they suggest that using the ROS binary environment together with Pixi is already a practical pattern.</p> <h2><a class="anchor" href="https://discourse.openrobotics.org#p-117379-possible-recommendation-5" name="p-117379-possible-recommendation-5"></a>Possible recommendation?</h2> <p>For ROS 2 distributions that provide/support the Pixi environment, I wonder whether the current practical recommendation could be something along these lines:</p> <blockquote> <p>Download a known ROS 2 Windows binary, reproduce its dependency environment with Pixi, and run colcon build/test explicitly.</p> </blockquote> <p>It has the advantage that the dependency environment stays close to the one used for the ROS 2 binary itself, while the workflow remains explicit about whether tests are actually executed.</p> <p>One additional safeguard may be worth recommending regardless of the setup: CI should fail if an expected package or test is not discovered. A green Windows job that actually ran zero tests is particularly easy to overlook.</p> <p>A few questions remain:</p> <ul> <li> <p>Is there already a maintained action or reusable workflow that encapsulates this pattern?</p> </li> <li> <p>Is there a recommended way to resolve a stable distro-specific Windows binary rather than hard-coding a dated release URL? For the experiment above I pinned Lyrical 2026-08-07.</p> </li> <li> <p>Is Windows test execution expected to return to <code>action-ros-ci</code>, or is another approach preferred?</p> </li> <li> <p>For distributions that do not provide the Pixi setup, what is the recommended Windows CI environment today?</p> </li> </ul> <p>If there is already a preferred solution, I would be interested in using and documenting that instead. Otherwise, it may be useful to turn the working Pixi-based pattern into a small reusable example so individual projects do not need to rediscover the same Windows setup details.</p> <h2><a class="anchor" href="https://discourse.openrobotics.org#p-117379-related-links-6" name="p-117379-related-links-6"></a>Related links</h2> <ul> <li><a href="https://discourse.openrobotics.org/t/github-actions-for-ros-and-ros-2-ci-beta/12755">GitHub Actions for ROS, and ROS 2 CI (beta)</a></li> <li><a href="https://discourse.openrobotics.org/t/windows-ci-builds-are-now-officially-containerized-and-virtualized-on-ci-ros2-org/13099">Windows CI builds are now officially containerized and virtualized on ci.ros2.org</a></li> </ul> <p><small>1 post - 1 participant</small></p> <p><a href="https://discourse.openrobotics.org/t/ros-2-windows-ci-on-github-actions-current-options-and-a-pixi-based-pattern/57736">Read full topic</a></p>