Skip to content

ci: build darwin-x86_64 natively on macos-15-intel#11

Merged
alexeagle merged 2 commits into
masterfrom
aeagle/charlie-bazel-release-darwin-x86_64-crosscompile
Jun 30, 2026
Merged

ci: build darwin-x86_64 natively on macos-15-intel#11
alexeagle merged 2 commits into
masterfrom
aeagle/charlie-bazel-release-darwin-x86_64-crosscompile

Conversation

@alexeagle

@alexeagle alexeagle commented Jun 30, 2026

Copy link
Copy Markdown

Problem

GitHub retired its Intel runner macos-13 on 2025-12-04 (changelog, runner-images#13046). The build darwin-x86_64 leg is pinned to macos-13, so it sits "awaiting a runner" until GitHub's 24h queue ceiling kills it — it never starts. Because release has needs: [..., build-darwin], this blocks the entire release.

That's what happened on run 28265340973: the other three legs built in ~15–17m, darwin-x86_64 timed out after 24h, and 8.6.0-figma2 shipped without bazel-8.6.0-figma2-darwin-x86_64 — Intel-Mac bazelisk gets a 404.

Why native (not cross-compile or Rosetta)

I first tried cross-compiling from an arm64 macos-14 runner (--cpu=darwin_x86_64 --macos_cpus=x86_64). It fails: abseil's randen_hwaes applies x86-only -maes/-msse4.1 to the arm64 exec-config build tools (clang++: error: unsupported option '-maes' for target 'arm64'), a known Bazel macOS cross-compile pitfall (bazelbuild/bazel#14803, #24264).

Upstream Bazel doesn't cross-compile either — its release CI builds each macOS arch natively on dedicated machines, via separate macos and macos_arm64 Buildkite queues (bazelci.py). No --cpu, no Rosetta anywhere.

Fix

Move the darwin-x86_64 leg to GitHub's native Intel image macos-15-intel (runner-images#13045) — the documented replacement for the retired macos-13. The build stays a plain native build (no --cpu flags, no emulation), identical in shape to the old macos-13 path.

  • darwin-x86_64 matrix leg: runner: macos-13macos-15-intel (keeps bazelisk_arch: amd64)
  • comment updated with root cause + a TODO(aeagle) for the ~Aug 2027 hosted-x86_64 sunset (move to a self-hosted Intel Mac or drop Intel then)

Test plan

  • workflow_dispatch a release; confirm build darwin-x86_64 picks up a macos-15-intel runner and builds natively (no 24h queue wait)
  • Confirm the published release includes bazel-<ver>-darwin-x86_64 (+ .sha256)
  • Confirm file reports a Mach-O x86_64 binary and it runs on a macOS Intel host

🤖 Generated with Claude Code

alexeagle and others added 2 commits June 30, 2026 16:16
GitHub retired its last Intel hosted runner (macos-13), so the
darwin-x86_64 release leg sat 24h "awaiting a runner" and never built,
blocking the whole release (run 28265340973) and shipping 8.6.0-figma2
without the macOS Intel asset.

Build darwin-x86_64 on macos-14 (Apple silicon) via
--cpu=darwin_x86_64 --macos_cpus=x86_64, using the arm64 bootstrap
Bazelisk for the host. This is exactly the cross-compile fallback the
prior code comment anticipated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Supersedes the --cpu cross-compile attempt, which failed: cross-compiling
darwin-x86_64 from an arm64 runner makes abseil's randen_hwaes apply
-maes/-msse4.1 to the arm64 exec-config tools (bazelbuild#14803).
Upstream Bazel avoids this by building each arch natively on dedicated
macOS machines (bazelci.py macos vs macos_arm64 queues); we do the same
using GitHub's native Intel image.

macos-13 was retired 2025-12-04, which is why the leg starved for a runner
and blocked the release (run 28265340973). macos-15-intel is GitHub's
replacement native x86_64 image (available until ~Aug 2027).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@alexeagle alexeagle changed the title ci: cross-compile darwin-x86_64 release on macos-14 ci: build darwin-x86_64 natively on macos-15-intel Jun 30, 2026
@alexeagle alexeagle marked this pull request as ready for review June 30, 2026 18:04
@alexeagle

Copy link
Copy Markdown
Author

LGTM thanks Claude

@alexeagle alexeagle merged commit 43a140b into master Jun 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant