fix(ci): install Zig from Homebrew for manual macOS builds - #2300
fix(ci): install Zig from Homebrew for manual macOS builds#2300cameronsjo wants to merge 1 commit into
Conversation
macos-latest now runs macOS 26, whose SDK is newer than the libSystem bundled with the pinned Zig 0.15.2. Linking the vendored libghostty-vt build runner fails with a wall of undefined libc symbols (_abort, _dispatch_semaphore_signal, __availability_version_check), so both macOS jobs in the manual workflow fail before compiling anything. release.yml already skips setup-zig on macOS and installs zig@0.15 from Homebrew for this reason; the manual workflow never picked that up. This applies the same two steps to its macOS job.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe macOS artifact workflow replaces ChangesmacOS Zig installation
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Greptile SummaryThis PR aligns the manual macOS artifact workflow with the existing release workflow to avoid incompatibility between the macOS 26 SDK and the standard Zig 0.15.2 distribution.
Confidence Score: 5/5The PR appears safe to merge because the manual macOS workflow now follows the repository’s established working Zig installation pattern. The Homebrew formula satisfies the vendored library’s Zig version requirement, is added to the PATH consumed by the Rust build script, and the change remains isolated to macOS artifact jobs.
|
| Filename | Overview |
|---|---|
| .github/workflows/build-artifacts-manual.yml | The macOS job now installs and exposes the patched Homebrew Zig formula using the same established sequence as the release workflow; no actionable defect was found. |
Reviews (1): Last reviewed commit: "fix(ci): install Zig from Homebrew for m..." | Re-trigger Greptile
|
we don't have any problem with ci so i don't understand what this pr tries to fix in the first place? ah you mean the manual workflow. but why would you want to fix that i don't even use it anymore? please dont tell your agents to find issues on herdr that you can open pr for :/ |
|
You're right. My agent took inspo from the wrong place and I blessed it. I didn't tell it to "find an issue", but I did experience the issue while doing local builds while building #2299. You're right that this was the wrong implementation of it though, and it doesn't fix the root cause being local builds on macOS 26 can be a bit hairy to get working. |
Build artifacts (manual)currently fails both macOS jobs before it compilesanything.
macos-latestnow runs macOS 26, whose SDK is newer than the libSystem bundledwith the pinned Zig 0.15.2. Linking the vendored libghostty-vt build runner dies
with a wall of undefined libc symbols:
release.ymlalready handles this. It gatesmlugg/setup-zigbehindif: runner.os != 'macOS'and installszig@0.15from Homebrew instead(
Install patched Zig on macOS). The manual workflow never picked that up, soit still calls
setup-zigunconditionally.This applies the same two steps to the manual workflow's macOS job: the Homebrew
download cache, then the
brew install zig@0.15that puts a Zig built againstthe current SDK on
PATH. The Linux and Windows jobs are untouched.Verification
Both runs are on the same tree; the only difference is this patch.
setup-zig0.15.2brew zig@0.15The resulting
aarch64-apple-darwinbinary runs on macOS 26 and reports theexpected version, so this is a build-host problem rather than anything wrong
with the vendored source.
Related: #285 covers the same SDK-versus-pinned-Zig mismatch for local macOS
builds. This only fixes CI.