v0.0.36

Add `rapids-get-artifact` (#36)

This PR introduces a small new function, `rapids-get-artifact`.

Given an artifact path, it will:

- download the artifact
- extract the artifact to a temporary directory
- echo the location of the temporary directory

**Example Usage:**

```sh
CUDF_CHANNEL=$(rapids-get-artifact ci/cudf/pull-request/12602/aa4da21/cudf_conda_python_cuda11_38_x86_64.tar.gz)

echo "$CUDF_CHANNEL" # prints a dir name like "/tmp/tmp.4BnKNJyyQg"
```

v0.0.35

Add `rapids-get-rapids-version-from-git` (#34)

This PR adds a new utility called `rapids-get-rapids-version-from-git`
which will get the RAPIDS version from the latest `git` tag in a repo.

v0.0.34

Generate stable version for pip wheel release builds (#33)

Currently in the pip wheel workflows, the flow is as follows:
* If the user does not input their desired stable version string (e.g.
`23.02.00`) as a workflow input, the script `rapids-pip-wheel-version`
generates it automatically with the following logic:
1. In the workflow, the epoch timestamp of the current build is
generated and passed as the argument: `rapids-pip-wheel-version
$epoch_timestamp`
    2. Script gets the tag via git describe tag --abbrev0: `v23.02.00a`
    3. Script removes letters: `23.02.00`
4. Script runs `distutils.normalize` (strips some leading 0s etc. by
python versioning rules): `23.2.0`
    5. Script appends the epoch timestamp: `23.2.0.$epoch_timestamp`
* If the user **does** input their desired stable version string as a
workflow input, that string is used directly as the wheel version.
However, in practice, the user always inputs the same thing that step 4
above generates from the git tag
* Therefore, it's much simpler to do the following:
    1. Drop the version override as a workflow input
    2. Embed the logic into the rapids-pip-wheel-version script:
a. If rapids-is-release-build: stop at step 4 (use `23.2.0` as a
version)
b. If **not** rapids-is-release-build: append the epoch timestamp
(`23.2.0.$epoch_timestamp`) as version (same behavior as before)

This PR adds the new behavior described.

This way we eliminate all user inputs and have automatic stable/nightly
versioning generated by the workflow.

v0.0.33

Allow packages to be skipped by `rapids-upload-to-anaconda` (#32)

### Problem

Most of the Anaconda packages that our libraries build are intended to
be published to Anaconda.org.

However, `cugraphops` has some packages that they don't wish to
distribute.

Currently the `rapids-upload-to-anaconda` script indiscriminately
uploads all `conda` packages that aren't test packages (e.g.
`libcudf-tests`, `libcugraph-tests`, etc) to Anaconda.org


### Solution

This PR adds a new script, `rapids-find-anaconda-uploads.py`, that is
used by `rapids-upload-to-anaconda` to determine the list of packages
that should be uploaded to Anaconda.org.

`rapids-find-anaconda-uploads.py` will find all of the conda packages
within a specified directory and filter out any test packages and any
packages listed in the `SKIP_UPLOAD_PKGS` environment variable.

This PR also includes some `pytest`s for
`rapids-find-anaconda-uploads.py`.

### Additional Notes

These changes are a bit awkward due to the fact that they introduce a
Python script into an otherwise all-bash script repository.

However, I think this decision is warranted due to the complexity of the
logic in `rapids-find-anaconda-uploads.py`.

I initially tried implementing it in bash, but found that it was very
verbose and difficult to understand.

The ergonomics of Python enabled the resulting script to be super
succinct and has the added benefit of being unit-testable.

v0.0.32

Add `rapids-check-pr-job-dependencies` script (#30)

This PR adds a new script, `rapids-check-pr-job-dependencies`.

This script is intended to be used in a new check job in the
`shared-action-workflows` repository.

The script checks the `pr-builder` job in the `pr.yaml` workflow file to
ensure that it depends on all of the other jobs in the workflow file.

This is necessary because our branch protections are configured to
depend on the `pr-builder` job, so it's implied that that job will
depend on all of the other jobs in the workflow.

Depends on https://github.com/rapidsai/ci-imgs/pull/30.

v0.0.31

Feat/pip wheel version script (#28)

* Add pip wheel version script

* add debugging to pip version script

* Rewrite rapids-twine in bash

* Address shellcheck suggestions

* Print debug statements to stderr

* Simplify rapids-pip-wheel-version

* Pass epoch timestamp into pip-version script

* Use set -u instead of rapids-require-env-var

v0.0.30

Replace `rapids-require-env-var` w/ `set -u` (#27)

v0.0.29

Add `rapids-retry` to `rapids-upload-to-anaconda` (#26)

It seems that some of our nightly jobs have been failing to upload to Anaconda.org due to transient connection errors (e.g. [this run](https://github.com/rapidsai/actions/actions/runs/3425490732/jobs/5706569717#step:6:107)).

This PR addresses that by adding `rapids-retry` to our `anaconda upload` command.

v0.0.28

print arch in `rapids-print-env`

v0.0.27

Update `rapids-upload-to-anaconda` Error Handling (#25)

In a recent GitHub Actions run ([link](https://github.com/rapidsai/rapids-cmake/actions/runs/3413106288/jobs/5679670752#step:6:11)), the `rapids-upload-to-anaconda` script failed due to missing AWS credentials. However, since the bash error handling wasn't configured properly, the GH Action run was reported as a success.

This PR updates the script to ensure that this issue doesn't happen again.

Note that `inherit_errexit` ([link](https://saveriomiroddi.github.io/Additional-shell-options-for-non-trivial-bash-shell-scripts/#inherit_errexit)) would also work for this use case, but it's only supported on `bash` versions `4.4+` and `centos7` has `bash` version `4.2`. So that option was skipped for this situation.