chore: change ci runners to reduce x86_64 macOS build time - #726
Open
evan-sift wants to merge 6 commits into
Open
chore: change ci runners to reduce x86_64 macOS build time#726evan-sift wants to merge 6 commits into
evan-sift wants to merge 6 commits into
Conversation
Collaborator
|
@evan-sift fyi, |
Wall clock for a release was ~42 minutes, dominated by the x86_64-apple-darwin job (41 min on the Intel macos runner pool) and the Windows job (30 min). - Build x86_64-apple-darwin on an arm64 macos-15 runner and cross-compile. dist adds the rustup target itself, and the vendored HDF5 CMake build produces x86_64 objects correctly. - Use RunsOn 8cpu runners for the Linux and Windows builds. The Linux label pins the ubuntu22 image to keep the glibc 2.35 baseline of the published binary. The labels are static because the matrix comes from the dist plan JSON, where GitHub expressions do not expand. - Set precise-builds so dist builds only sift_cli with --package. The workspace build also compiled sift_stream_bindings (pyo3), which is not part of the CLI release and fails to link when cross-compiling. The workflow YAML is unchanged: dist computes the runner matrix at plan time from dist-workspace.toml.
Verifies the new RunsOn and arm64 macos runners on the PR itself. Revert before merge.
evan-sift
force-pushed
the
ci/bigger-release-runners
branch
from
August 11, 2026 21:28
4bae82c to
1b86362
Compare
The RunsOn stack in this org does not serve Windows jobs; the job sat queued indefinitely on PR #726 while the Linux RunsOn job ran fine.
A release job stranded in the queue while an identical label was served minutes earlier; stale spot capacity is the usual cause of intermittent runs-on strands. On-demand instances remove that failure mode; azimuth pins spot=false the same way for jobs that must not stall.
This reverts commit 1b86362.
evan-sift
changed the title
evan-sift
marked this pull request as ready for review
August 12, 2026 00:09
evan-sift
commented
Aug 12, 2026
Comment on lines
+20
to
+23
| # Build only sift_cli with `--package` instead of the whole workspace. The | ||
| # workspace build compiles sift_stream_bindings (pyo3), which is not part of | ||
| # the CLI release and fails to link when the apple target is cross-compiled. | ||
| precise-builds = true |
Collaborator
Author
There was a problem hiding this comment.
is this correct?
Contributor
There was a problem hiding this comment.
I found the docs on precise-builds and it seems like it probably will result in smaller builds based on this description. But the docs on github-custom-runners don't seem to show options for runner and host, but maybe they just aren't documented well?
solidiquis
approved these changes
Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
when updating ALL runners to be better, here are the rough diffs:
so I think if we just update the
x86_64 macOS (arm64 cross)runner, that will be sufficient, since now we're bottlenecked by windows. reverted the changes I had for Linux andarm64 macOSsince the ~16m fall within the 30m bounds now