Pin Swift macOS PR checks to macOS 15 for Xcode 16#3971
Conversation
`macos-latest-xlarge` now resolves to macOS 26, which ships only Xcode 26 (Swift 6.2) and no longer includes Xcode 16. The Swift-analysing PR checks select Xcode 16 because CodeQL CLI versions before 2.24.0 only support Swift up to 6.1, so `xcode-select -s /Applications/Xcode_16.app` fails on macOS 26. Pin these checks to macOS 15, where Xcode 16 is still available, so we keep testing the full matrix of supported CodeQL versions. This also pre-empts the `swift-custom-build` check failing once plain `macos`/`macos-latest` migrates. See actions/runner-images#14167. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rather than pinning every macOS job to macOS 15, only run the older CodeQL CLI versions (which need Xcode 16, and so macOS 15) there. Newer versions, which support Swift 6.2, run on the latest macOS runner with its default Xcode, so we keep exercising the common latest-CLI-on-latest-runner combination. To express this, `sync.ts` now supports an optional per-OS-entry `codeql-versions` filter, used by `multi-language-autodetect` to send old versions to `macos-15-xlarge` and new versions to `macos-latest-xlarge`. `swift-custom-build` only runs `linked`/`default`/`nightly`, which all support Swift 6.2, so it no longer needs the Xcode 16 step or a macOS 15 pin. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Warning
- Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.
Pull request overview
This PR updates the PR-check workflow generation to allow selecting different macOS runner images per CodeQL CLI version, addressing recent macos-latest(-xlarge) migrations that removed Xcode 16 (needed by older CodeQL CLIs for Swift).
Changes:
- Extend
pr-checks/sync.tsjob-matrix generation to support per-OS-entrycodeql-versionsfiltering. - Update
multi-language-autodetectto split macOS runs acrossmacos-latest-xlarge(newer CLIs) andmacos-15-xlarge(older CLIs), selecting Xcode 16 only on the macOS 15 runner. - Remove the Xcode 16 selection step from
swift-custom-build(note: the template currently still targets movingmacos-latestunless additionally pinned).
Show a summary per file
| File | Description |
|---|---|
| pr-checks/sync.ts | Adds codeql-versions support so a single check can map different CodeQL versions to different runner images. |
| pr-checks/checks/multi-language-autodetect.yml | Splits macOS coverage between newer and older CodeQL CLI versions using different runner-image labels; gates Xcode 16 selection to macOS 15. |
| pr-checks/checks/swift-custom-build.yml | Removes explicit Xcode 16 selection step; currently still uses unpinned macos runner selection in the template. |
Copilot's findings
Files excluded by content exclusion policy (2)
- .github/workflows/__multi-language-autodetect.yml
- .github/workflows/__swift-custom-build.yml
- Files reviewed: 3/5 changed files
- Comments generated: 1
mbg
left a comment
There was a problem hiding this comment.
Thanks for addressing those comments! This looks OK to merge, but with one maintenance concern and one question about the included CodeQL versions.
Redesign the per-entry codeql-versions filter so an OS entry without a version list catches all versions not claimed by its siblings. This lets new CodeQL versions flow to macos-latest-xlarge automatically. Move v2.23.9 (which supports Swift 6.2) off the macOS 15 list and simplify the matrix filter logic. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
mbg
left a comment
There was a problem hiding this comment.
Looks good, thanks! Nothing blocking here, just one comment that resulted from my experience reviewing the most recent change. Feel free to merge as-is.
| // For each OS, collect the CodeQL versions explicitly claimed by entries that specify | ||
| // `codeql-versions`. A sibling entry for the same OS that omits `codeql-versions` runs all | ||
| // versions not in this set. | ||
| const claimedVersionsByOs = new Map<string, Set<string>>(); |
There was a problem hiding this comment.
Minor: This mapping is indexed by the .os key, which is shared among all siblings. The "claimedVersionsByOs" naming here is therefore a bit confusing because it seems to say something about which OS has claimed which versions. Changing this to e.g. handledVersionsByOS or similar might be slightly clearer.
There was a problem hiding this comment.
I'll leave this as is so we can get the checks passing on main 👍
The
macos-latest-xlargelabel has started resolving to macOS 26, which ships only Xcode 26 (Swift 6.2) and no longer includes Xcode 16. Our Swift-analysing PR checks explicitly select Xcode 16 (xcode-select -s /Applications/Xcode_16.app) because CodeQL CLI versions before 2.24.0 only support Swift up to 6.1. That step now fails on macOS 26, which is why the Multi-language repository check is red.We still want to exercise the full matrix of supported CodeQL versions (back to 2.19.4) against Swift, so we can't simply move to Xcode 26. Instead, this pins the affected checks to macOS 15, where Xcode 16 is still available:
multi-language-autodetect:macos-latest-xlarge->macos-15-xlargeThis restores the runner that
macos-latest-xlargepointed at before the migration, so it is a known-good configuration. The generated__*.ymlworkflows were regenerated vianpm run update-pr-checks. Once the minimum supported CodeQL version reaches 2.24.0, these checks can drop the Xcode 16 pin and move back tomacos-latest.The nightly-only Swift checks (
swift-autobuild,export-file-baseline-information) are intentionally left on macOS 26, since nightly CodeQL supports Swift 6.2 with the default Xcode.See actions/runner-images#14167.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Environments:
How did/will you validate this change?
pr-checks).If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist