Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add workflow to upload conda packages to legate channel #173

Merged
merged 11 commits into from
Oct 30, 2024
8 changes: 6 additions & 2 deletions .github/workflows/build.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,8 @@ on:
branches:
- "main"
- "release/v[0-9][0-9].[0-9][0-9].[0-9][0-9]"
# run on pushes of new release tags
# run on pushes of any tags
tags:
- v[0-9][0-9].[0-9][0-9].[0-9][0-9]
# run by clicking buttons in the GitHub Actions UI
workflow_dispatch:

Expand All @@ -22,6 +21,11 @@ jobs:
with:
script: "ci/build_python.sh"
secrets: inherit
upload-conda:
needs:
- conda-python-build
uses: ./.github/workflows/conda-upload-packages.yaml
secrets: inherit
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding this here, with these triggers:

on:
# run on pushes to certain branches
push:
branches:
- "main"
- "release/v[0-9][0-9].[0-9][0-9].[0-9][0-9]"
# run on pushes of new release tags
tags:
- v[0-9][0-9].[0-9][0-9].[0-9][0-9]
# run by clicking buttons in the GitHub Actions UI
workflow_dispatch:

Means that new legate-boost packages will automatically be published to the legate channel in the following situations.

Scenario 1: New packages pushed to the experimental label, with version like {YY}.{MM}.{patch}.dev{n}

  • new commit pushed to main
  • new commit pushed to any branch named release/v{YY}.{MM}.{patch}
  • new tag pushed which does not exactly match the pattern v[0-9][0-9].[0-9][0-9].[0-9][0-9]
  • someone manually clicked the "run workflow" button in GitHub Actions UI

Scenario 2: New packages pushed to the main label, with version like {YY}.{MM}.{patch} (i.e. a stable release)

  • new tag pushed exactly matching the pattern v[0-9][0-9].[0-9][0-9].[0-9][0-9]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds reasonable to me. The only downside would be that release branch nightlies are probably not used much and use disk-space/build time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only downside would be that release branch nightlies are probably not used much and use disk-space/build time.

The release/ branches should only be used for hotfixes, in the way I've proposed setting this up:

### Hotfixes

I'm thinking of the case where @danielfrg or someone reports a bug, and we merge a fix and want to say "ok we have a release candidate of like 24.09.01.dev3, can you test it?"

It'd be useful to have a nightly package for that testing, I think, so we can build confidence in that fix before officially releasing a new version and so the tester doesn't have to build from source or download a GitHub Actions artifact.

I don't know if we really need nightlies for all tags

Here, I'm thinking about the specific case where, say, we just cut stable release 24.09.00 and are ready to begin work on 24.12.00.dev{n}. Was thinking that in that case, we want a first build to run when development starts, so you immediately have nightlies with that version (and the corresponding versions of cunumeric / legate) to use.

See #171 (comment)

docs-build:
needs:
- conda-python-build
Expand Down
39 changes: 39 additions & 0 deletions .github/workflows/conda-upload-packages.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
# adopted from https://github.com/rapidsai/shared-workflows/blob/branch-24.12/.github/workflows/conda-upload-packages.yaml
# with some notable differences:
#
# * assumes packages were uploaded to GitHub artifact store, not Amazon S3
# * always publishes to the same channel, but uses different label for non-release packages
#

on:
# run only when called by other workflows
workflow_call:

env:
# where jobs that download conda packages store the local channel
RAPIDS_LOCAL_CONDA_CHANNEL: /tmp/local-conda-packages

jobs:
upload:
runs-on: linux-amd64-cpu4
container:
image: rapidsai/ci-conda:latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
# the notebooks and PNG files stored in git LFS aren't necessary for package uploads
lfs: false
- name: download conda packages
uses: actions/download-artifact@v4
with:
# omitting 'name' here means "download all artifacts from this run"... useful to
# avoid having to list the matrix of CUDA / Python versions here
path: ${{ env.RAPIDS_LOCAL_CONDA_CHANNEL }}
github-token: ${{ secrets.GITHUB_TOKEN }}
repository: ${{ github.repository }}
run-id: ${{ github.run_id }}
- name: Upload packages
run: "ci/upload-to-anaconda.sh"
env:
CONDA_LEGATE_TOKEN: ${{ secrets.CONDA_LEGATE_TOKEN }}
2 changes: 0 additions & 2 deletions .github/workflows/github-actions.yml
Original file line number Diff line number Diff line change
Expand Up @@ -23,8 +23,6 @@ jobs:
# group together all jobs that must pass for a PR to be merged
# (for use by branch protections)
pr-builder:
# skip on builds from merges to main
if: github.ref != 'refs/heads/main'
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that this workflow file is only triggered on pull requests, this condition is unnecessary.

needs:
- pre-commit
- conda-python-build
Expand Down
24 changes: 18 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -75,13 +75,25 @@ model = lb.LBRegressor(base_models=(lb.models.KRR(sigma=0.5), lb.models.Tree(max

## Installation

If you already have `cunumeric` and `legate` installed, run the following:
Install using `conda`.

```shell
pip install \
--no-build-isolation \
--no-deps \
.
# stable release
conda install -c legate -c conda-forge -c nvidia legate-boost

# nightly release
conda install -c legate/label/experimental -c legate -c conda-forge -c nvidia legate-boost
```

On systems without a GPU, the CPU-only package should automatically be installed.
On systems with a GPU and compatible CUDA version, the GPU package should automatically be installed.

To force `conda` to prefer one, pass the build strings `*_cpu*` or `*_gpu*`, for example:

```shell
# nightly release (CPU-only)
conda install --dry-run -c legate/label/experimental -c legate -c conda-forge -c nvidia \
'legate-boost=*=*_cpu*'
```

For more details on customizing the build and setting up a development environment, see [`contributing.md`](./contributing.md).
For more details on building from source and setting up a development environment, see [`contributing.md`](./contributing.md).
39 changes: 39 additions & 0 deletions ci/upload-to-anaconda.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
#!/bin/bash

# adopted from https://github.com/rapidsai/gha-tools/blob/main/tools/rapids-upload-to-anaconda,
# with some notable differences:
#
# * assumes artifacts are on GitHub Actions artifact store, not Amazon S3
# * assumes packages have been unpacked to env variable RAPIDS_LOCAL_CONDA_CHANNEL
# * does not differentiate between pull request and nightly branches
# (relies on workflow triggers to just not run this script when it isn't needed)

set -e -E -u -o pipefail

# publish to the 'experimental' label on the 'legate' channel, for all cases except
# releases (builds triggered by pushing a tag matching this regex exactly, e.g. 'v24.09.00')
if [[ "${GITHUB_REF}" =~ ^refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
declare -r conda_label="main"
else
declare -r conda_label="experimental"
fi

PKGS_TO_UPLOAD=$(rapids-find-anaconda-uploads.py "${RAPIDS_LOCAL_CONDA_CHANNEL}")

if [ -z "${PKGS_TO_UPLOAD}" ]; then
rapids-echo-stderr "Couldn't find any packages to upload in: ${RAPIDS_LOCAL_CONDA_CHANNEL}"
ls -l "${RAPIDS_LOCAL_CONDA_CHANNEL}/"*
fi

rapids-echo-stderr "Uploading packages to Anaconda.org (channel='legate', label='${conda_label}'):"
rapids-echo-stderr "${PKGS_TO_UPLOAD}"

# shellcheck disable=SC2086
RAPIDS_RETRY_SLEEP=180 \
rapids-retry anaconda \
-t "${CONDA_LEGATE_TOKEN}" \
upload \
--label "${conda_label}" \
--skip-existing \
--no-progress \
${PKGS_TO_UPLOAD}
8 changes: 7 additions & 1 deletion conda/recipes/legate-boost/conda_build_config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -25,5 +25,11 @@ gpu_enabled:
- true
- false

cunumeric_version:
# .dev116: https://github.com/nv-legate/legate.core.internal/issues/1409
- "=24.09.*,>=0.0.0.dev0,!=24.09.00.dev116"

legate_version:
- "=24.09.*,>=0.0.0.dev0"
# .dev319: https://github.com/nv-legate/legate.core.internal/pull/1401
# .dev329: https://github.com/nv-legate/legate.core.internal/issues/1409
- "=24.09.*,>=0.0.0.dev0,!=24.09.00.dev319,!=24.09.00.dev329"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should try this approach of !=-ing past nightlies that cause incompatibilities here. This is preferable to == pinning to an older version, because it means that if the bugs we've reported upstream get fixed, then CI will just automatically start pulling in the new nightlies.

And if they aren't, then we'll get feedback from CI of the form "the bug we reported has still not been fixed".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the != approach. When we start using a newer version, we can convert the != to > (just to not pile up blocklisted versions)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

convert the != to >

Yes definitely, agreed!

8 changes: 4 additions & 4 deletions conda/recipes/legate-boost/meta.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -79,11 +79,11 @@ requirements:
{% if gpu_enabled_bool %}
- cuda-version ={{ cuda_version }}
- cuda-cudart-dev
- cunumeric {{ legate_version }} =*_gpu*
- cunumeric {{ cunumeric_version }} =*_gpu*
- legate {{ legate_version }} =*_gpu*
- libcublas-dev
{% else %}
- cunumeric {{ legate_version }} =*_cpu*
- cunumeric {{ cunumeric_version }} =*_cpu*
- legate {{ legate_version }} =*_cpu*
{% endif %}
- openblas
Expand All @@ -99,9 +99,9 @@ requirements:
# cuda-version is used to constrain __cuda
- {{ pin_compatible('cuda-version', max_pin='x', min_pin='x') }}
- __cuda
- cunumeric {{ legate_version }} =*_gpu*
- cunumeric {{ cunumeric_version }} =*_gpu*
{% else %}
- cunumeric {{ legate_version }} =*_cpu*
- cunumeric {{ cunumeric_version }} =*_cpu*
{% endif %}
# Relying on run_exports from legate to pin an appropriate range of versions and
# GPU vs. CPU selector.
Expand Down
10 changes: 5 additions & 5 deletions contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -223,8 +223,8 @@ git push origin update-version
```shell
git checkout main
git pull upstream main
git tag -a v24.12.00dev -m "v24.12.00dev"
git push upstream v24.12.00dev
git tag -a v24.12.00.dev -m "v24.12.00.dev"
git push upstream v24.12.00.dev
```

From that point forward, all packages produced by CI from the `main` branch will have versions like `v24.12.00.dev{n}`,
Expand All @@ -251,8 +251,8 @@ git commit -m 'start v24.09.01 [skip ci]'
git push upstream release/24.09

# tag the first commit on the new branch as the beginning of the 24.09.01 series
git tag -a v24.09.01dev -m 'v24.09.01dev'
git push upstream v24.09.01dev
git tag -a v24.09.01.dev -m 'v24.09.01.dev'
git push upstream v24.09.01.dev
```

2. Open pull requests targeting that branch and merge them into that branch.
Expand Down Expand Up @@ -283,7 +283,7 @@ git cherry-pick release/v24.09

NOTE: The use of `cherry-pick` here is important because it re-writes the commit IDs. That avoids the situation where e.g. the
`v24.09.01` hotfix tag points to commits on the `main` branch during `v24.12` development (which could lead to those packages
incorrectly getting `v24.09.01dev{n}` versions).
incorrectly getting `v24.09.01.dev{n}` versions).

3. Open a pull request to merge that branch into `main`.
4. Perform a non-squash merge of that pull request.
Expand Down