Repository navigation
ci: support macOS 27 (Xcode 27 SDK) - #26
Conversation
The CI matrix gains a macos-26 leg so clippy/tests run against the Xcode 27 toolchain alongside the macos-15 floor, and the release workflow packages the macOS universal bundle on it — published artifacts are built with the newest SDK while LSMinimumSystemVersion (13.0) keeps older systems working. Verified locally on macOS 27.0: full test suite passes and the packaging pipeline (universal build, codesign, DMG) runs end to end.
![hedgehog-pr-bot[bot]](https://avatars.githubusercontent.com/in/4663470?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pi code review
The PR adds a macos-26 leg to the CI matrix, moves macOS release packaging from macos-15 to macos-26, and updates README/BUILDING.md to advertise macOS 27 (Xcode 27 SDK) support. I checked the workflow changes for runner-label validity, toolchain selection, artifact impact, concurrency/trigger interactions, and doc consistency, and the doc edits for consistency with the CI changes. No functional code or security issues. The main concern: both workflows assert that the macos-26 image carries the Xcode 27 toolchain (macOS 27 SDK), but nothing in either workflow selects or verifies an Xcode version — the builds will silently use whatever the image's default toolchain is, and GitHub's image naming has consistently paired macos-N images with Xcode N as the default (e.g. macos-15 → Xcode 16). If macos-26 defaults to Xcode 26, the shipped DMG/zip and the CI "newest-SKU" leg are built with the macOS 26 SDK, contradicting the title, the inline comments, README, and BUILDING.md. Secondary: the BUILDING.md sentence "Builds with Xcode 26 or 27" doesn't describe the CI floor (macos-15 builds with an older default Xcode), and these unpinned version claims will drift as images update.
ℹ️ 1 Medium · ℹ️ 2 Low
Reviewed 867a23f with Pi 0.85.1 using zai/glm-5.3:high.
| # Build with the newest macOS/Xcode SDK: the published universal | ||
| # binary then carries the macOS 27 SDK's platforms support while | ||
| # still deploying to older systems (LSMinimumSystemVersion 13.0). | ||
| runs-on: macos-26 |
There was a problem hiding this comment.
Medium: This job claims to package with "the newest macOS/Xcode SDK" (and the title/README/BUILDING.md say Xcode 27 / macOS 27 SDK), but nothing here selects or verifies an Xcode version — the build uses the runner image's default toolchain. Per GitHub's image convention (macos-15 → Xcode 16, macos-14 → Xcode 15), a macos-26 image most likely defaults to Xcode 26 with the macOS 26 SDK, so the published universal binary may be built with a different SDK than every doc in this PR asserts, with no signal. Suggest explicitly selecting the toolchain (e.g. sudo xcode-select -s /Applications/Xcode_27.app, or maxim-lobanov/setup-xcode@v1 with xcode-version: '27') and adding a step that prints xcodebuild -version and xcrun --show-sdk-version --sdk macosx (failing if it isn't the expected one) so the SDK baked into release artifacts is guaranteed and auditable.
| fail-fast: false | ||
| matrix: | ||
| os: [macos-15, ubuntu-24.04, windows-2025] | ||
| # macos-26 carries the Xcode 27 toolchain (macOS 27 SDK): the |
There was a problem hiding this comment.
Low: The comment states as fact that macos-26 "carries the Xcode 27 toolchain (macOS 27 SDK)", but nothing pins or checks that — the leg exercises whatever the image default is. If the default is Xcode 26, the "newest-SKU" leg is not testing the Xcode 27 toolchain the PR claims, and the comment will go stale as images update. Either select Xcode explicitly (see the release job) or add a cheap xcodebuild -version / xcrun --show-sdk-version --sdk macosx log step, and phrase the comment as "newest available runner image" rather than a specific Xcode version.
|
|
||
| ### macOS | ||
|
|
||
| Builds with Xcode 26 or 27 (macOS 26/27 SDK); the universal package is |
There was a problem hiding this comment.
Low: "Builds with Xcode 26 or 27 (macOS 26/27 SDK)" doesn't match what CI actually does: the macOS floor leg (macos-15) builds with that image's default Xcode, and no workflow pins Xcode 26 vs 27, so these specific version claims will silently drift as GitHub updates images. Consider wording it as "builds with the runner image's default Xcode — CI covers the oldest supported image (macos-15) and the newest (macos-26), and release packaging uses the newest SDK" — or pin the versions so the sentence is enforceable.
1 participant
What
macos-26leg: clippy, tests, and a release build run against the Xcode 27 toolchain (macOS 27 SDK) alongside the existingmacos-15floor.macos-26: published DMG/zip artifacts are built with the newest SDK. The universal binary still deploys to older systems —LSMinimumSystemVersionstays 13.0 and the rust target minimum is unchanged.Verification
scripts/package-macos.sh— the exact release pipeline: universal build, ad-hoc codesign, styled DMG — runs end to end.macos-26runner label: if GitHub hasn't shipped that image yet, the job will sit queued and this PR should not merge.