Run CI for branch builds with GitHub Actions #11747
Conversation
Eric-Arellano
changed the title
[ci skip-rust] [ci skip-build-wheels]
[ci skip-rust] [ci skip-build-wheels]
[ci skip-rust] [ci skip-build-wheels]
[ci skip-rust] [ci skip-build-wheels]
Eric-Arellano
force-pushed
the
branch-builds
branch
from
51a4922
to
44bb830
Compare
| @@ -159,12 +182,12 @@ def expose_all_pythons() -> Sequence[Step]: | |||
| ] | |||
|
|
|||
|
|
|||
| def test_workflow_jobs(python_versions: Sequence[str]) -> Jobs: | |||
| def test_workflow_jobs(primary_python_version: str) -> Jobs: | |||
There was a problem hiding this comment.
Nit: this was a list because we expect to add 3.9 to cron sometime soon.
There was a problem hiding this comment.
Ack, although I'm thinking we can add that back once it's ready. There are some unknowns still like that native_engine.so is different across Py38 and Py39, so we need to cache it twice. It's not as simple as setting python_versions to both Py38 and Py39 to run them both in cron.
For now, this makes the Build Wheels code a bit more clear because there, we will always activate 3.7, 3.8, and 3.9 at the same time.
There was a problem hiding this comment.
Ack, although I'm thinking we can add that back once it's ready. There are some unknowns still like that native_engine.so is different across Py38 and Py39, so we need to cache it twice. It's not as simple as setting python_versions to both Py38 and Py39 to run them both in cron.
It's a matrix job, so it might be that simple...? 🤞
Eric-Arellano
changed the title
|
Interesting. The cancel workflow ends up canceling branch builds if a newer PR is merged while still running. I don't think we want that. We could fix this according to https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run by adding a second predicate that the branch cannot == |
|
Yeah that sounds right. |
Fixes up #11747 so that we always build for `main` and release branches, even if a newer commit lands during a CI run.
|
Looks like this runs the "Daily Extended Python Testing" on the main branches of forks, which we probably don't want or need? |
We want to run on branch builds to ensure there were no regressions after merging PRs, such as due to racy merges.