Switch to Depot runners in CI #426
Conversation
|
Exciting! One downside is non-Astral folk won't be able to test the CI on their forks because they won't have access to the private/paid runners. We have a similar situation for CPython, we use Cirrus M1 runners for upstream and fallback to GitHub's |
|
Ah yeah that's a good point I hadn't fully considered. I'll open an issue to track that. I'm sure we can have fallback runners, just will take a second :) |
|
Yeah it's really fun to see all the Linux jobs run concurrently |
zanieb
force-pushed
the
zb/depot-runners
branch
from
12c1911 to
851d901
Compare
|
That Windows job failed twice? But I don't see what could be different, we're still using a Windows 2022 runner. It's just a larger GitHub provided runner. This didn't fail in previous testing. |
|
Alright, third time's the charm — something seems to be legitimately wrong with that specific combination. |
Generates the CI matrix dynamically so we can run subsets on pull
requests.
- Moves the matrix definition out of GitHub workflows into a
`ci-targets.yaml` file
- Adds a `ci-matrix.py` script which parses the `ci-targets.yaml` file
and outputs a JSON matrix
- Updates the GitHub Actions workflows to use the script to generate a
matrix dynamically
- Uses the labels on the pull request to allow subsetting of the matrix
For example, you can run the matrix generator locally to see the label
subsetting in action:
```console
❯ uv run ci-matrix.py --label arch:x86_64,platform:linux,libc:gnu,build:freethreaded,build:lto | jq
Reading inline script metadata from `ci-matrix.py`
{
"include": [
{
"arch": "x86_64",
"target_triple": "x86_64-unknown-linux-gnu",
"platform": "linux",
"libc": "gnu",
"run": "true",
"python": "3.13",
"build_options": "freethreaded+pgo+lto"
},
{
"arch": "x86_64",
"target_triple": "x86_64_v2-unknown-linux-gnu",
"platform": "linux",
"arch_variant": "v2",
"libc": "gnu",
"run": "true",
"python": "3.13",
"build_options": "freethreaded+pgo+lto"
},
{
"arch": "x86_64",
"target_triple": "x86_64_v3-unknown-linux-gnu",
"platform": "linux",
"arch_variant": "v3",
"libc": "gnu",
"run": "true",
"python": "3.13",
"build_options": "freethreaded+pgo+lto"
},
{
"arch": "x86_64",
"target_triple": "x86_64_v4-unknown-linux-gnu",
"platform": "linux",
"arch_variant": "v4",
"libc": "gnu",
"python": "3.13",
"build_options": "freethreaded+lto"
}
]
}
```
I'll add labels for
- `platform:darwin`
- `platform:linux`
- `platform:windows`
- `python:3.9`
- `python:3.10`
- `python:3.11`
- `python:3.12`
- `python:3.13`
- `build:debug`
- `build:pgo`
- `build:lto`
- `build:noopt`
- `build:freethreaded`
- `arch:x86_64`
- `arch:aarch64`
- `arch:armv7`
- `arch:s390x`
- `arch:ppc64le`
- `arch:x86`
- `libc:gnu`
- `libc:musl`
In a follow-up, I'll update this to use different runners in forks as
noted in #426
|
If Depot doesn't have macOS x86-64 runners, how does PGO work? Are the aarch64 macOS machines running x86-64 in emulation mode and using that to train the PGO? x86-64 macOS is becoming vanishingly rare. (I'm typing this from a 2018 Intel MBP, which is barely usable.) So the loss of real PGO on this platform may not be a huge deal. My experience with the x86-64 emulation is it is often fast/approximate enough. It's probably good enough. 🤷♂️ |
|
That's.. a good question. They must be running in emulation mode and I didn't notice because it's faster. Interesting. I guess we should benchmark and see if there's a regression? I don't have the hardware to do so myself though. |
Exploring a solution to #426 (comment)
Otherwise, the jobs here will consume our concurrency limits and block CI organization-wide. The Depot runners will give us greater concurrency limits, and notably, avoid colliding with our GitHub Runner limits — which are very low for macOS in particular.
Also, uses larger GitHub Actions runners for Windows.I've reverted this because there's a new, inexplicable failure for 32-bit 3.12Note that Depot doesn't support x86_64 macOS so we're now cross-compiling those. I previously verified the artifact was correct.