[CI] Cross-platform — Part 1: pytest markers and shared scaffolding (base)

[hujc7]

Summary

Base PR for cross-platform CI on Windows and NVIDIA DGX Spark (ARM/aarch64 Linux). No user-facing API change.

• Registers windows, windows_ci, arm, arm_ci pytest markers in pyproject.toml.
• AppLauncher argv strip recognizes the new markers so pytest -m windows_ci (etc.) does not leak into Isaac Sim's argparse.
• AssetConverterBase USD scratch dir: hardcoded /tmp/IsaacLab → tempfile.gettempdir() for cross-platform compatibility.
• Tags source/isaaclab/test/deps/test_torch.py + test_scipy.py with the new markers so future cross-platform CI jobs can select them.

Prior art and credits

This work is a derivative of and builds directly on two prior PRs by other contributors:

• test windows CI #3900 by Kelly Guo (kellyguo11), against main, 2025-10-31 — "test windows CI". Designed and introduced the cross-platform marker scheme (windows, windows_ci, arm, arm_ci), tagged ~50 existing tests across the codebase, added the AppLauncher argv-strip pattern so the new pytest -m filters do not leak into Isaac Sim's argument parser, and pioneered the Windows CI job wiring. The marker design and AppLauncher behavior in this PR are taken directly from test windows CI #3900.
• Adds basic CI verification on Windows #3845 by Alexander Poddubny (nv-apoddubny), against main, 2025-10-27 — "Adds basic CI verification on Windows". Built the original Windows self-hosted runner infrastructure: isaaclab.bat entry script, the initial .github/workflows/build.yml Windows job, and the self-hosted-runner labeling conventions this PR's downstream Part 2/Part 3 workflows still rely on.

Both PRs target main and have not been merged. This PR rebases that work onto develop (where the active development happens — main is behind by hundreds of commits), reduces the initial test surface to a small starter set (test_torch.py + test_scipy.py) to validate the marker/runner plumbing end-to-end before re-expanding, and adds an arm_ci marker variant + ARM/Spark runner support that #3900/#3845 did not include.

Credit for the architecture goes to the authors above; this PR is the rebase + minimization step.

Series

PRs prefixed with [CI] Cross-platform — all contribute to bringing Isaac Lab CI up on Windows and NVIDIA DGX Spark runners. This PR is the base everything else builds on. Current siblings:

• Part 1 (this PR, base) — Markers and shared scaffolding
• Part 2 — [CI] Cross-platform — Part 2: ARM/Spark workflow #5698 — ARM/Spark workflow (.github/workflows/arm-ci.yaml)
• Part 3 — [CI] Cross-platform — Part 3: Windows workflow #5700 — Windows workflow (.github/workflows/windows-ci.yaml)

Siblings depend on this PR's marker scheme; the same scaffolding lines are carried in their branches and dedupe on rebase after this lands. Additional follow-up parts can be added later without renumbering existing ones.

Test plan

• pytest --collect-only -m windows_ci source/isaaclab/test/deps/ returns the marked tests.
• pytest --collect-only -m arm_ci source/isaaclab/test/deps/ returns the same set.
• ./isaaclab.sh -f (pre-commit) passes.

[isaaclab-review-bot]

🤖 Isaac Lab Review Bot

Update (2026-05-20): Reviewed new commits (b5e57a6 → 9242498).

Changes Since Last Review

The PR scope has been refined - workflow files (cross-platform-ci.yaml) have been removed. This PR now focuses purely on foundational infrastructure:

• ✅ Pytest marker registration (windows, windows_ci, arm, arm_ci)
• ✅ AppLauncher argv stripping for new CI markers
• ✅ Cross-platform temp directory (tempfile.gettempdir())
• ✅ Test files annotated with new markers

Previous Concerns Status

Issue	Status
continue-on-error double-masking	🔵 N/A - workflow files removed from PR
ARM PyTorch cu128 wheel compatibility	🔵 N/A - workflow files removed from PR
Stale virtualenv risk	🔵 N/A - workflow files removed from PR
Missing base markers in tests	⚪ Minor - still only _ci variants used

✅ Current State: Looks Good

This is now a clean foundation PR. The workflow files will presumably ship in follow-up PRs (as mentioned in the changelog skip message). No blocking concerns.

---

This is an automated review.

---

Update (commit 1e32138): The new commits simplify the marker system by removing windows and arm base markers from pyproject.toml (keeping only windows_ci and arm_ci). Additionally, module-level pytestmark annotations were removed from test_scipy.py and test_torch.py.

Previous concerns:

• ⚪ "Missing base markers in tests" → ✅ Resolved by design — base markers eliminated entirely.

New issues: None. This is a clean simplification that reduces marker surface area. No regressions introduced.

[greptile-apps]

Greptile Summary

This PR lays the scaffolding for cross-platform CI on Windows and ARM/Spark by registering four new pytest markers, teaching AppLauncher to strip them from sys.argv, moving the USD scratch directory from /tmp to tempfile.gettempdir(), and tagging the existing test_torch.py / test_scipy.py dep tests with the new markers.

• pyproject.toml: Adds windows, windows_ci, arm, and arm_ci markers — clean and complete.
• asset_converter_base.py: Replaces hardcoded /tmp/IsaacLab with os.path.join(tempfile.gettempdir(), \"IsaacLab\", ...) — correct cross-platform fix with no behavior change on Linux.
• app_launcher.py / test files: windows_ci and arm_ci are now stripped from sys.argv; test_scipy.py tagging is safe, but all test_torch.py tests hardcode device=\"cuda:0\", which will hard-fail on any CI runner that does not expose a CUDA GPU.

Confidence Score: 3/5

Safe to merge with awareness of the CUDA dependency in test_torch.py; the core scaffolding changes are correct but the torch test tagging could silently break future CI runs on GPU-less runners.

The tempfile fix and marker registrations are straightforward and correct. However, all six torch tests now tagged for windows_ci and arm_ci unconditionally allocate tensors on cuda:0. If either CI runner ever lacks a CUDA device the entire test_torch suite will hard-fail before a single assertion is checked, which defeats the purpose of marking them as cross-platform runnable.

source/isaaclab/test/deps/test_torch.py — all tests hardcode cuda:0 despite being tagged for cross-platform CI runners.

Important Files Changed

Filename	Overview
pyproject.toml	Adds four new pytest markers (windows, windows_ci, arm, arm_ci) — straightforward and complete.
source/isaaclab/isaaclab/app/app_launcher.py	Extends argv stripping to cover windows_ci and arm_ci; bare windows and arm markers are registered but not stripped.
source/isaaclab/isaaclab/sim/converters/asset_converter_base.py	Replaces hardcoded /tmp/IsaacLab with tempfile.gettempdir() via os.path.join — correct cross-platform fix.
source/isaaclab/test/deps/test_torch.py	Tagged windows_ci and arm_ci at module level, but all test functions hardcode device="cuda:0" — will hard-fail on any runner without CUDA.
source/isaaclab/test/deps/test_scipy.py	Tagged windows_ci and arm_ci at module level; all tests are CPU-only so the tags are safe across platforms.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["pytest -m windows_ci / arm_ci"] --> B["sys.argv contains -m marker"]
    B --> C["AppLauncher._create_app()"]
    C --> D{"marker in strip list?"}
    D -- "windows_ci / arm_ci stripped" --> E["Remove -m + value from sys.argv"]
    D -- "windows / arm NOT stripped" --> F["Leaks into Isaac Sim argparse"]
    E --> G["SimulationApp initialised cleanly"]
    H["pytest collects test_torch.py"] --> I{"CUDA available?"}
    I -- "cuda:0 present" --> J["Tests pass"]
    I -- "No CUDA" --> K["RuntimeError: No CUDA GPUs"]
    L["asset_converter_base.py"] --> M["tempfile.gettempdir()"]
    M --> N["Linux: /tmp/IsaacLab/usd_..."]
    M --> O["Windows: %TEMP%/IsaacLab/usd_..."]

Loading

_{Reviews (1): Last reviewed commit: "[CI] Add Windows + ARM pytest markers an..." | Re-trigger Greptile}

[greptile-apps]

CUDA-only tests tagged for cross-platform CI

Every test function in this file uses device="cuda:0" unconditionally (e.g. torch.rand(size, device="cuda:0")). Tagging the whole module with windows_ci and arm_ci means these tests will be collected and run on those platforms, but they will immediately fail with RuntimeError: No CUDA GPUs are available on any runner that does not expose cuda:0. If both Windows and ARM Spark runners are guaranteed to have an NVIDIA GPU, consider adding a pytest.mark.skipif(not torch.cuda.is_available(), reason="CUDA not available") guard so the suite degrades gracefully rather than hard-failing on platforms where CUDA is absent.

[greptile-apps]

The bare windows and arm markers are registered in pyproject.toml but are not included in the argv-stripping filter. If a developer runs pytest -m windows (or -m arm) on a test that also initialises AppLauncher, those tokens will leak into Isaac Sim's argparse — the same failure mode this block was originally written to prevent.

Suggested change

	if (
	"pytest" in value_for_dash_m
	or "isaacsim_ci" in value_for_dash_m
	or "windows_ci" in value_for_dash_m
	or "arm_ci" in value_for_dash_m
	):
	if (
	"pytest" in value_for_dash_m
	or "isaacsim_ci" in value_for_dash_m
	or "windows_ci" in value_for_dash_m
	or "windows" in value_for_dash_m
	or "arm_ci" in value_for_dash_m
	or "arm" in value_for_dash_m
	):

[kellyguo11]

are these new annotators necessary for this check? I think this was initially added for the isaac sim pipeline to work properly by making sure the correct arguments gets passed over. will that also be impacted by the windows and arm annotations?

[hujc7]

It's for pytest selecting tests, which uses the same mechanism as isaacsim_ci tag. While this is not quite scalable at the moment, some investigation into argparse refactor should help. e.g. to only pass appLauncher recognized arguments to it.

[AntoineRichard]

Are we not running the the whole batch of tests on windows? Would it make sense to make a specific test shard just for windows? (that would remove the annotation)

[kellyguo11]

would this be a lot of maintenance to tag every test that would work on windows? I think most of our workflows should support windows already with a few exceptions. perhaps it's easier to mark the ones that are not supported instead?

[hujc7]

As a start, I think whitelist should be better. Windows pool size is also just 1/4 compare to linux ones. I can test on the overall duration + test support and see if a negative tag works better, but I think that will be in followup PRs given that windows still have driver + isaacsim develop access issue not resolved.
The PR serves as the common setup for followups so they can all go independently.

[kellyguo11]

I see, then is there a need to keep both windows and windows_ci tags? I was thinking if we have both, windows could be a blacklist that determines which tests are not supported on windows. and windows_ci could be a whitelist that enables a small set of tests to run

[hujc7]

"windows" is dropped, and only "windows_ci" is added in the latest patch. Personally, I would whitelist should be sufficient and it's more verbose at per test/file level that where the test runs.

[AntoineRichard]

I'm not sure what's best between annotated tests and a specific test shard for windows / arm.

[AntoineRichard]

Are we not running the the whole batch of tests on windows? Would it make sense to make a specific test shard just for windows? (that would remove the annotation)

[AntoineRichard]

Is this better than a specific shard?

[hujc7]

Not exactly sure what a shard means here. Does it mean selecting the tests at workflow level? If so, I am trying to make it obvious at test level all the configuration.