wheels-publish: 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)

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-conda = 4.5 - 5.5 GB

(rapidsai/ci-wheel DockerHub link)