-
Notifications
You must be signed in to change notification settings - Fork 5.3k
[release/8.0] Move default build images to macos 15 (and xcode 16) (#120589) #122423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/8.0] Move default build images to macos 15 (and xcode 16) (#120589) #122423
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR updates the default macOS build images from macOS 13 to macOS 15 (with Xcode 16) for public builds, and adds test exclusions for Swift interop stress tests that are incompatible with the new environment.
- Updates public macOS build pool to use 'macos-15' image
- Adds documentation comment explaining that build platforms should always use the latest available version
- Excludes Swift ABI stress tests for mono minijit x64 configuration due to known issues on the new platform
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| eng/pipelines/common/xplat-setup.yml | Updates public macOS pool from 'macos-13' to 'macos-15' and adds policy comment about using latest platform versions |
| src/tests/issues.targets | Adds test exclusions for Swift interop stress tests (SwiftRetAbiStress and SwiftCallbackAbiStress) for mono minijit x64 configuration, referencing issue #121983 |
|
@steveisok it looks like mono build is failing. Any insight? |
Taking a look. |
lambdageek
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is cherrypicking from c48aa81
I don't remember the subtleties anymore, but this seems right
|
@steveisok I think you also need c48aa81#diff-b2942ad0f35c702862be561fa03e56f885e6b362b4b5522a21e23cc4d9e444ba the aot-compiler.c changes |
|
On runtime/src/mono/mono/mini/decompose.c Line 221 in ac34532
has runtime/src/mono/mono/mini/decompose.c Line 220 in 30a5c7c
fixed here: |
Thanks! |
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
|
From David: this smells like some sort of corruption, not debuggable from a trace. We'll need a dump and probably access to one of the Helix machines + a live repro. |
|
I can repro the issue locally executing the bits from the failed run pulled by runfo. And yet it works perfectly fine if I build it locally using exactly the same XCode tools version, repeating exactly the command lines that CI uses to build the stuff on my arm64 mac running the whole build under rosetta so that it matches build on x64 mac. |
|
Update: I can repro it with local build now, I haven't realized libraries tests on macOS use release build of the runtime. |
Co-authored-by: Eric StJohn <[email protected]> Co-authored-by: Matous Kozak <[email protected]> (cherry picked from commit eaafd7c) (cherry picked from commit 1905046)
…and mess things up.
…ncorrect transformations by the ld64/ld-prime linkers
93ef2d6 to
b1df24b
Compare
|
Looks like there is a consistent crash in |
|
I believe we are running into #97966 as a result of the bump. @dotnet/ncl can you please confirm? I'd like to move this forward as 8.0 servicing is blocked until we can get this PR in. |
|
@steveisok do you have details about the reliable crash? @rzikm @wfurt @liveans should be able to help ... |
I didn't try to get a managed stack yet, but I think the native one gives a pretty good indicator it's the issue I linked to. |
|
gssapi was buggy on MacOS and we switched to managed implementation for NTLM. But I think we still use it for Kerberos/Negotiate. It seems like the new MacOS has more problems and that will need to be investigated. |
|
ah, it seems like the comment says it was resolved in .NET 9+ #97966 |
Do you think it's related to gss and not a runtime issue? If so, I think we can move this forward and decide what to do separately. |
|
I think taking this PR, even with System.Net.Http failing, is better than the alternative. We currently have no working Mac builds. At worst we get a Mac build with a bug in one area. /ba-g Known issue in HTTP tests and dead letter in other queues |
I agree. No complaints from me :-) |
(cherry picked from commit eaafd7c) (cherry picked from commit 1905046)