Skip to content

Enable WSL testing in CI #114

Open
Open

Description

@vyasr

Currently RAPIDS claims support for WSL but only tests this support via ad hoc testing on individual machines. The primary purpose of this testing is to verify that the CUDA driver in WSL2 works properly and handles everything that RAPIDS libraries need. We would like to be able to run these tests in a more systematic manner, ideally in CI. However, there are currently a number of blockers for this. This issue is meant for tracking the various tasks that must be accomplished in order to get CI testing on WSL2.

  1. Windows GPU runners: Currently we have some limited support for Windows runners. We do not have WSL2 support because you cannot do nested virtualization on the EC2 runners. Enabling WSL will require that we transition CI to NVKS. That is currently being handled by @ajschmidt8's team.
  2. WSL2 vs WSL: It looks like currently the Windows VMs that we have support for on our runners are installing WSL. We would like to get these running WSL2. The nested virtualization requirement discussed above is only for WSL2, not WSL1, so we need to address 1 above before we can switch to WSL2 on GPU runners. However, we could update our setup to use WSL2 as long as we are just testing on CPU runners.
  3. We need to figure out how to set up the WSL2 instance so that it is ready to run everything that we need to test RAPIDS libraries, including perhaps installing Docker.
  4. We need scripts to actually run tests. This can be worked on by individual libraries.

Activity

  1. vyasr commented on Oct 28, 2024

    @vyasr
    ContributorAuthor

    I may work with @wmaxey on 2/3 as time permits.

  2. bdice commented on Nov 3, 2026

    @bdice
    Contributor

    I started an experiment in rapidsai/rmm#2339. I'm going to see what I can do to test this a bit more.

  3. bdice commented on Nov 3, 2026

    @bdice
    Contributor

    WSL CI rollout

    We'll add WSL test jobs using the migration-matrix process in MATRIX_GUIDELINES.md, the same way as the CUDA 13.4 migration (#335). WSL only adds test jobs (no new builds), so library PRs can merge in any order.

    New jobs (OS: 'wsl', runner wsl-amd64-gpu-<GPU>-latest-1):

    • conda-cpp-tests
      • wsl-pr: amd64, py3.12, CUDA 13.0.3, ubuntu24.04, rtxpro6000
      • wsl-nightly: amd64, py3.12, CUDA 13.0.3, rockylinux8, rtxpro6000
    • wheels-test
      • wsl-pr: amd64, py3.14, CUDA 13.4.3, ubuntu24.04, h100
      • wsl-nightly: amd64, py3.12, CUDA 13.0.3, ubuntu24.04, h100

    Infrastructure PRs

    Library PRs

    add wsl-pr / wsl-nightly to matrix_type for conda-cpp-tests and wheels-test jobs, fix any WSL-specific test failures, merge in any order once CI passes

    Other follow-up (after all library PRs)

    • shared-workflows: move the WSL jobs into the pull-request / nightly matrices, replacing equivalent Linux jobs to keep the matrix size constant
    • remove wsl-pr / wsl-nightly from matrix_type in all libraries (GitHub search)

    Cleanup after everything else above

    • shared-workflows: remove wsl-pr / wsl-nightly matrices
    • shared-workflows: delete the old wsl branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions