re-organize build matrices

[jameslamb]

Contributes to rapidsai/build-planning#3

Related to rapidsai/build-planning#5

Proposes re-organizing the build matrices.

Specifically:

• using the same order of keys within each matrix entry, across different workflow configurations
• sorting all matrices in ascending order by the same keys
• adding extra whitespace so all entries for the same key are vertically aligned
• using comments to visually distinguish between amd64 and arm64 jobs
  • (extra tough to see visually because those 2 strings are so similar and so short)

Benefits of these changes

I believe the proposed changes here will make changes like "add a new CUDA version" or "drop support for a Python version" easier to author and review.

Inspired by 2 recent experiences I've had where I proposed changes to the build matrices and both I and reviewers found them difficult to assess:

• add support for python 3.11 #176
• add CUDA 12.2 conda and wheel jobs #166

I hope this re-organization will make it easier to determine at a glance whether matrices are achieving goals like:

• "good balance across Python versions"
• "covering all CUDA {major}.{minor} RAPIDS wants to support"
• "at least one job with latest Python, latest CUDA, latest operating system"

Notes for Reviewers

To be clear, this is is only a moving-code-around PR.

It does not propose any changes to the build matrices for any workflows. If you see any places where this PR would lead to adding a new type of job or dropping a job that's currently being run, that's a mistake.

How I tested this

Opened rapidsai/cudf#15111 to test.

The matrix of jobs there (https://github.com/rapidsai/cudf/actions/runs/7994808681/job/21834408169?pr=15111) looks identical to the most recent successful run from some other PR targeting branch-24.04 (https://github.com/rapidsai/cudf/actions/runs/7992742449).

Also spot-checked the logs to confirm that we were getting the right runner architecture, Python version, CUDA version, and operating system.

Some of the job names did change... I think because we don't specify name: explicitly in the workflows here, so they're auto-generated based on the matrix entries.

(left = before, right = as of this PR)

I don't think that should affect the correctness of branch protections, since we have this mechanism:

shared-workflows/.github/workflows/pr-builder.yaml

Lines 1 to 9 in da626b6

	on:
	workflow_call:
	jobs:
	run:
	runs-on: ubuntu-latest
	steps:
	# This reusable workflow should depend on all other jobs in the calling workflow.
	- run: exit 0

That's discussed over in #118.

[jameslamb]

/merge

[msarahan]

[jameslamb]

haha thanks @msarahan .

@ajschmidt8 could you merge this?

[msarahan]

let's see if I have any power here...

/merge

[bdice]

[jameslamb]

Thanks @bdice !

[bdice]

I don’t think this repo uses /merge commands? I’m not sure if that’s intentional or an oversight.

Also FYI, the comment must be only /merge and not a message containing /merge. @msarahan’s attempt would not have worked because it had content before the /merge.

[jameslamb]

Thanks for that! For the record, I didn't have the green merge button available, so either way I suspect I don't have sufficient access to merge here.