wheels CI: reduce CI time

[jameslamb]

Description

The wheels-publish workflow is responsible for a pretty narrow purpose... downloading wheel artifacts built in CI and publishing them to package repositories (like https://pypi.anaconda.org/rapidsai-wheels-nightly/simple/).

It really only needs a Python interpreter and a couple tools like twine, the anaconda CLI, and the gh CLI.

Today, it uses the rapidsai/ci-wheel container images (build from rapidsai/ci-imgs), which are around 4.5 GB compressed (https://hub.docker.com/r/rapidsai/ci-wheel/tags).

The time to run that workflow is dominated by container-image pulling. For example, look at a recent wheels-publish-cudf job (build link):

This issue tracks the work of designing and implementing changes to speed that up. Maybe some mix of:

• using a slimmer container image (or just ubuntu-latest / ubuntu-slim runners without a container)
• removing telemetry
• using a shallow git checkout

Benefits of this work

• reduced end-to-end time for RAPIDS nightly pipeline (https://github.com/rapidsai/workflows/actions/workflows/nightly-pipeline.yaml)
• reduced time to roll out a change across all of RAPIDS (related: Rebuild the world button build-planning#238)
• reduced usage of CI resources

Acceptance Criteria

• wheels-publish workflows are faster than they were on February 17, 2026

Ideas

Just dumping some ideas here, this is not an implementation plan:

• use ubuntu-latest / ubuntu-slim GitHub-hosted runners
• use a smaller container image (like python:latest or python:3.13-slim)
• create a new rapidsai/ci-wheel-publishing or similar image
  • publishing a new image does bring new legal / compliance requirements though, this might be a lot of effort
• fiddle with the rapidsai/ci-wheel image
  • different compression?
  • fewer layers?
  • removing unused things?
• use shallow git checkouts
• remove telemetry (this workflow doesn't benefit much from it)

Approach

Related changes made since this started:

• remove docs files and build artifacts, consolidate RUN steps (smaller images: remove docs files and build artifacts, consolidate layers ci-imgs#368)
• clear caches, remove unnecessary pyenv stuff (smaller images: clean caches, delete unnecessary pyenv stuff ci-imgs#394
• more parallelization, skip unnecessary stuff like docs and tests in source builds of CPython and its dependencies (speed up wheel image builds ci-imgs#425)
• stop shipping llvm in Ubuntu citestwheel images (citestwheel: stop shipping LLVM in Ubuntu images ci-imgs#428)
• remove source checkouts and telemetry from package-publishing jobs (remove git clones and telemetry for package-publishing jobs, use full semver tags for third-party actions #585)
• use a different, faster-to-pull base image for wheel-publishing (run package uploads in python slim containers #586)
• use nvidia/cuda:*-base-* or similar for citestwheel (refactor(citestwheel): switch base image from devel to base ci-imgs#408)

Notes

N/A

[jameslamb]

Looking more closely, not all of this is specific to the wheels-publish jobs. In general, the rapidsai/ci-wheel images take longer to pull onto our runners than rapidsai/ci-conda images.

Looking a recent cuDF PR CI run, using a common platform (x86_64 + CUDA 12.9 + Python 3.11 + rockylinux8)

rapidsai/ci-conda = 46s

rapidsai/ci-wheel = 3m6s

ref: https://github.com/rapidsai/cudf/actions/runs/22339634959

Clicking around RAPIDS CI for different repos and jobs I see this pattern consistently... rapidsai/ci-wheel takes around 3-5x longer to pull than rapidsai/ci-conda.

Many factors can affect pull times, but one clear place to start is total image size... and the ci-wheel images really are a lot bigger.

rapidsai/ci-conda = 600-750 MB

(rapidsai/ci-conda DockerHub link)

rapidsai/ci-wheel = 4.5 - 5.5 GB

(rapidsai/ci-wheel DockerHub link)