ci(binaries): cross-build the Intel Mac from Apple silicon - #64
Merged
Conversation
On the v0.6.2 release the x86_64-apple-darwin leg sat queued for forty-five minutes while every other target finished inside ninety seconds. GitHub is winding the Intel runners down, and a target nobody can schedule is a target that silently stops shipping. It does not need one. Xcode's toolchain and SDK are universal, so an arm64 runner produces an x86-64 binary with nothing but rustup target add -- no sysroot to fetch, no linker to configure. The job now asks file what it actually built and fails if the answer is not the architecture the target names. A cross-build that quietly produced the host's architecture would pass every other check here and fail on the first machine that downloaded it, which is the one failure mode this change introduces and therefore the one worth checking. Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
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
1 participant
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.
Short answer to "should we cancel the Intel Mac build": no — but it should stop needing an Intel runner.
The problem is scheduling, not the target
On the v0.6.2 release the
x86_64-apple-darwinleg sat queued for 45 minutes while every other target finished inside ninety seconds:GitHub is winding the Intel runners down. A target nobody can schedule is a target that silently stops shipping — which is worse than one that is cross-built, and much worse than one you decided to drop on purpose.
It does not need an Intel runner
Xcode's toolchain and SDK are universal. An arm64 Mac produces an x86-64 binary with nothing but
rustup target add x86_64-apple-darwin— no sysroot to fetch, no linker to configure, nocross. Both macOS targets now build onmacos-latest.The failure this introduces, and the check for it
Cross-building has exactly one new way to go wrong: producing the host's architecture while claiming the target's. That would pass the build, pass packaging, pass the checksum, upload cleanly — and fail on the first Intel Mac that downloaded it.
So the job now asks
filewhat it actually built:and fails loudly otherwise. Verified the matcher discriminates in both directions before committing it:
filesaysx86_64-apple-darwin… x86_64aarch64-apple-darwin… arm64x86_64-apple-darwin… arm64aarch64-apple-darwin… x86_64Non-macOS targets skip it — Linux and Windows are built natively and have nothing to confuse.
If you would rather drop it
Dropping
x86_64-apple-darwinis defensible: Apple stopped selling Intel Macs in 2023 and the population shrinks monthly. But that should be a decision, not an accident of runner availability — and while it costs one cross-compile on a runner we are already paying for, keeping it seems the easier call.Once merged I will re-dispatch for
v0.6.2and confirm the uploaded archive really is Intel.