v0.0.205

rapids-wheels-anaconda-github: use a stable directory for uploads (#264)

#263 broke the path in `wheels-publish` workflows where we upload to PyPI.

The relevant code there expects packages to be in `dist/` ([rapidsai/shared-workflows - .github/workflows/wheels-publish.yaml](https://github.com/rapidsai/shared-workflows/blob/3f5f9d01f3873916bf830fdc3e0fd684ccc0befb/.github/workflows/wheels-publish.yaml#L149)), but in #263 I replaced that with `mktemp`.

```text
ERROR    InvalidDistribution: Cannot find file (or expand pattern): 'dist/*'    
Error: Process completed with exit code 1.
```

([jupyterlab-nvdashboard build link](https://github.com/rapidsai/jupyterlab-nvdashboard/actions/runs/28184382922/job/83483178079))

This proposes making that location configurable, so that related steps can all share the same value.

## Notes for Reviewers

Deployment order:

1. merge this PR
2. wait for new images to be built: https://github.com/rapidsai/ci-imgs/actions/workflows/push.yaml
3. merge `shared-workflows` PR: https://github.com/rapidsai/shared-workflows/pull/583

Authors:
  - James Lamb (https://github.com/jameslamb)

Approvers:
  - Gil Forsyth (https://github.com/gforsyth)

URL: https://github.com/rapidsai/gha-tools/pull/264

v0.0.204

rapids-wheels-anaconda-github: support sdists (#263)

I'd like to start publishing sdists for `jupyterlab-nvdashboard`, to help with repackaging it on conda-forge: https://github.com/rapidsai/jupyterlab-nvdashboard/pull/283

This proposes updating `rapids-wheels-anaconda-github` to also look for sdists in the downloaded CI artifacts, and upload them to `anaconda.org`.

I *think* this is the only change needed in `ci-imgs` / `gha-tools`/ `shared-workflows` to support publishing sdists to the RAPIDS nightly index.

## Notes for Reviewers

### But... the name has `*-wheels-*` in it

I know, I know.

There are a lot of places where we use "wheel" to really mean _"thing that `pip` knows how to install"_.

In my opinion, living with the misnomer for now is preferable to generalizing more of these names. That should absolutely be revisited if we find ourselves building more sdists (related: https://github.com/rapidsai/build-planning/issues/99#issuecomment-2316032847).

### Other required changes?

Nothing needs to change in `ci-imgs`, `shared-workflows`, or any repo-specific build scripts 😁 

Projects that build sdists will automatically have them uploaded, projects that don't should be unaffected.

### How I tested this

On a `jupyterlab-nvdashboard` PR. Built like this:

```shell
python -m build --sdist --wheel
```

Saw `rapids-wheels-anaconda-github` correctly find and upload both the sdist and wheel.

see https://github.com/rapidsai/jupyterlab-nvdashboard/pull/283/changes#r3455486684

Authors:
  - James Lamb (https://github.com/jameslamb)

Approvers:
  - Bradley Dice (https://github.com/bdice)
  - Gil Forsyth (https://github.com/gforsyth)

URL: https://github.com/rapidsai/gha-tools/pull/263

v0.0.203

refactor(rapids-get-pr-artifact): rework tool for new artifact naming…

v0.0.202

refactor(rapids-artifact-name): add explicit `--arch` flag to overrid…

v0.0.201

fix(ci): resolve all zizmor findings and add zizmor pre-commit checks…

v0.0.200

fix(rapids-artifact-name): handling for "true" pure artifacts vs. cud…

v0.0.199

feat: add `rapids-artifact-name` (#253)

This is part of rapidsai/build-planning#270

It adds a new tool `rapids-artifact-name` that handles naming more consistently.

The arguments are:

`rapids-artifact-name package_type package_name repo --cuda [version] --py [version] --stable --pure`

`--stable`, `--py [version]`, and `--pure` are mutually exclusive and are only available when naming `python` artifacts.

```sh
> rapids-artifact-name conda_cpp librmm rmm --cuda 12.9
rmm_conda_cpp_librmm_amd64_cu12

> rapids-artifact-name wheel_cpp librmm rmm --cuda 12.9
rmm_wheel_cpp_librmm_amd64_cu12

> rapids-artifact-name conda_python pylibcudf cudf --cuda 13.1 --stable
cudf_conda_python_pylibcudf_amd64_abi3_cu13

> rapids-artifact-name wheel_python pylibcudf cudf --cuda 13.1 --stable
cudf_wheel_python_pylibcudf_amd64_abi3_cu13

> rapids-artifact-name wheel_python dask-cudf cudf --cuda 13.1 --pure
cudf_wheel_python_dask-cudf_amd64_pure_cu13

> rapids-artifact-name wheel_python dask-cudf cudf --pure
cudf_wheel_python_dask-cudf_amd64_pure
```

I tested this in https://github.com/rapidsai/rmm/pull/2370 by vendoring the script as written there (along with some related small changes to `shared-workflows` to allow overriding artifact names in the conda cpp builds)

Authors:
  - Gil Forsyth (https://github.com/gforsyth)

Approvers:
  - Jake Awe (https://github.com/AyodeAwe)

URL: https://github.com/rapidsai/gha-tools/pull/253

v0.0.198

Print `uname -a` instead of `arch` in `rapids-print-env` (#251)

v0.0.197

Fix malformed versions from push-triggered builds on release branches…

v0.0.196

rapids-get-pr-artifact: stricter, fewer API calls, less expensive (#249)

I've been using `rapids-get-pr-artifact` a lot recently, for https://github.com/rapidsai/build-planning/issues/257

Today, one of my PRs for that briefly caused `cudf` to briefly exceed its GitHub API limits: https://github.com/rapidsai/cudf/pull/21671#discussion_r2908165082

This proposes some fixes to `rapids-get-pr-artifact` in the future:

* error out of a unique GitHub Actions run ID can't be determined from the inputs
  - *(instead of passing an empty string to `gh run download`, which causes it to page over **all CI runs GitHub's history retains**)*
* limit initial search for runs to just `pr.yaml` workflow
  - *(optionally overridable by env variable `RAPIDS_BUILD_WORKFLOW_NAME`)*

These should make `rapids-get-pr-artifact` faster and, more importantly, use many fewer GitHub API calls.

## Notes for Reviewers

### Haven't I seen this before?

Yep! Similar changes were made in `rapids-github-run-id`:

* #193
* #170

`rapids-get-pr-artifact` doesn't use `rapids-github-run-id` because its behavior of "use environment variable `GITHUB_RUN_ID` if it's available" is undesirable when you're trying to workflow runs in a repo other than the one `rapids-get-pr-artifact` is currently running in.

### How I tested this

Tested on https://github.com/rapidsai/cudf/pull/21671, with https://github.com/rapidsai/cudf/pull/21671/commits/c058c439a34a3f8b7efaa2f8408c309ef61ec319

Authors:
  - James Lamb (https://github.com/jameslamb)

Approvers:
  - Gil Forsyth (https://github.com/gforsyth)

URL: https://github.com/rapidsai/gha-tools/pull/249