Releases: rapidsai/gha-tools
Releases · rapidsai/gha-tools
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.