split up PR and nightly/release CI

[jameslamb]

Contribute sto #115

Splits up CI into 2 different workflows:

• github-actions (runs on PRs, does not publish docs)
• build (runs on merges to main or new tags or via clicking a button in the UI, publishes docs to https://rapidsai.github.io/legate-boost/)

This is a step towards having workflows that automatically publish to the legate channel. In such builds, it's not necessary to re-run tests.

Notes for Reviewers

I'll leave notes inline on the diff explaining the specific design choices here.

How to test this

When this PR is merged into main, we should see a new run of this build workflow. In its logs, we should see package builds, docs builds, and docs publishing, but no tests.

The version in the top corner of https://rapidsai.github.io/legate-boost/ should match the version number from the corresponding package build in that same run.

After that, I'm going to put up another PR that wires up the publishing to the legate conda channel.

Helpful References

See "Reusing workflows" (GitHub docs) for explanation of the syntax.

The structure and naming I'm using is trying to follow RAPIDS conventions... but unlike the non-Legate RAPIDS projects, which get all their workflow definitions from a central public repo (https://github.com/rapidsai/shared-workflows), this is proposing checking those workflow files in directly here.

Maybe in the future, we could have a similar repo of shared workflows for the various RAPIDS legate-* projects. Let's defer that for now and just focus on getting legate-boost working as an example.

[jameslamb]

I realized that the "or PRs targeting those branches" part of this was wrong. That'd only be true with this very-similar-looking construct:

on:
  pull_request:
    branches:
      - main

(example from numpy)

But here in the rapidsai or, we avoid that by having the copy-pr-bot copy PR branches to branches named pull-request/, and only using on.push: types of conditions.

[jameslamb]

With these removals, this workflow will now only run on pull-request/ branches, and therefore only on PRs. The new file build.yaml (matching naming conventions from the rest of RAPIDS) will be responsible for running on merges to main or pushes of new tags.

[jameslamb]

everything below here is identical to what was in github-actions.yml, except that the literal ci/build_python.sh has been replaced by ${{ input.script }}, so that we have the option to use different scripts in the future.

[jameslamb]

🎉 this worked!

Merging this triggered this job: https://github.com/rapidsai/legate-boost/actions/runs/11487624682/job/31972594782

Notice:

• only builds, no tests (14m total)

• packages had the expected version

BUILD START: ['legate-boost-24.06.01dev7-cuda12_py310_0_gpu.conda']

• docs were built and deployed, with that same version

https://rapidsai.github.io/legate-boost/