run package uploads in python slim containers - #586
Conversation
| # CUDA toolkit version of the container is irrelevant in the publish step. | ||
| # This just uploads already-built wheels to remote storage. | ||
| image: "rapidsai/ci-wheel:26.08-latest" # zizmor: ignore[unpinned-images] | ||
| image: "python:3.14-slim" |
There was a problem hiding this comment.
We shouldn't meaningfully be impacted by Python version here, as long as it's an officially-supported version.
I chose not to use python:latest here to reduce the risk of these builds failing if :latest becomes (for example) 3.16.0rc1 and there aren't yet compatible wheels from some dependencies we pip install.
| uses: nv-gha-runners/setup-proxy-cache@main | ||
| continue-on-error: true | ||
| with: | ||
| enable-apt: true |
There was a problem hiding this comment.
Now that code in this workflow runs apt-get install and pip install, we'll want the proxy cache for faster downloads and reduced risk of network issues.
| # install gha-tools | ||
| git clone --depth 1 --branch test-uploads https://github.com/rapidsai/gha-tools /tmp/gha-tools | ||
| echo "/tmp/gha-tools/tools" >> "${GITHUB_PATH}" | ||
| export PATH="/tmp/gha-tools/tools:${PATH}" |
There was a problem hiding this comment.
GITHUB_PATH doesn't take effect until the next step, but we want gha-tools to be on PATH for rapids-pip-retry in this step.
| else | ||
| gh api /rate_limit | jq . | ||
| fi | ||
| gh api /rate_limit | jq . |
There was a problem hiding this comment.
We're now explicitly installing gh as part of this workflow. gh not being available would be a bug and we should get a loud error telling us about it.
|
I agree that Question: with the CuPy floor getting bumped up to I believe the cupy floor was the last thing (pending some tests runs...) holding us back from switching over to smaller images |
bdice
left a comment
There was a problem hiding this comment.
Looks fine to me. Feel free to use your admin powers to test with RMM as needed.
Yes, I think that's correct -- let's try to revive rapidsai/ci-imgs#408 once rapidsai/build-planning#279 is complete. |
I think yes, we should do BOTH, and we shouldn't couple them. Using a smaller base image for And this PR has the benefit of totally decoupling publishing from the content of the |
Co-authored-by: Bradley Dice <bdice@bradleydice.com>
Co-authored-by: James Lamb <jaylamb20@gmail.com>
|
/merge |
## Description Follow-up to #2458 Testing in `shared-workflows` is complete now that rapidsai/shared-workflows#586 has been merged. This resets all branch references for `shared-workflows` back to `main`. ## Checklist - [x] I am familiar with the [Contributing Guidelines](https://github.com/rapidsai/rmm/blob/HEAD/CONTRIBUTING.md). - [x] New or existing tests cover these changes. - [x] The documentation is up to date with these changes.
|
I've reset |
rapidsai/shared-workflows#586 switched the `conda-upload-packages` and `wheels-publish` jobs away from using this repo's images... they new use a `python:*-slim` image and install the tools they need at runtime. As a result, `rapidsai/ci-{conda,wheel}` no longer need to install `anaconda client`, the client library for anaconda.org. This proposes removing it. It pulls in a lot of dependencies, so this should help a bit with build times and image size (don't have estimates). ## Notes for Reviewers ### Is this safe? I think so. It appears the only remaining use of this is in `rapidsai/legate-{boost,dataframe}`, which aren't being actively developed: * `rapidsai`: https://github.com/search?q=org%3Arapidsai+%22anaconda+%22+AND+NOT+is%3Aarchived&type=code * `NVIDIA`: https://github.com/search?q=org%3ANVIDIA+%22anaconda+%22+AND+NOT+is%3Aarchived&type=code&p=3 Authors: - James Lamb (https://github.com/jameslamb) Approvers: - Gil Forsyth (https://github.com/gforsyth) URL: #432
Contributes to #505
As described there, it's not uncommon for pulling the
rapidsai/ci-wheelimages to take 3-4 minutes.This is extra painful for jobs like
wheels-publish, which just need lightweight publishing tools and not CUDA libraries, compiler toolchain, etc.This PR proposes working around that by doing the following:
python:3.14-slimimage insteadwheels-publishjobNotes for Reviewers
Benefits
conda-uploads-packagesandwheels-publish, which means reduced end-to-end time for RAPIDS nightly pipeline (see "how I tested this")anaconda-clientand its dependencies in therapidsai/ci-condaandrapidsai/ci-wheelimages at https://github.com/rapidsai/ci-imgsCosts / Risks
wheels-publish, which might lead to more transient failures from network issuesWhy not pre-build a
wheels-publishimage?That WOULD make this even faster and avoid all those package installs at runtime.
But new images need to go through a compliance/legal approval process that's a bit heavier than this use case justifies, in my opinion. In my testing, installing tools took 15-20 seconds, so that's the most we'd save by having a pre-built image with everything installed.
How I tested this
rmm'smainbranch was already pointed at this branch for package-uploading jobs from #585.Put up changes in a
gha-toolsbranch (rapidsai/gha-tools#265) to force-overwrite existing packages, so the upload time to anaconda.org is included in the timings.Clicked "re-run all jobs" on
rmm's most recent run onmain.main(as of #585)builds from
rmm: (previous main | this PR)