chore: upgrade macos runner to macos-13 Ventura and xcode15 #13606
Conversation
daschuer
changed the title
|
Will this increase the runtime requirements as well? |
|
This virtually drops the still supported macOS Monterey (V 12) form 2021-08. Mixxx 2.6 is scheduled earliest at 2025.06 (after 2.5 + 60 day + beta) https://github.com/mixxxdj/mixxx/wiki/250_release_proposal Conclusion: The other question is the XCode version. macOS 13.0 comes with XCode 14.1 Here is the readme describing the GitHub runner: So it looks like this will not limit the Mixxx binary support, but may be a barrier for contributors? For now I think we should stick to the default pair macOS 13 + XCode 14.1 |
|
Since GitHub defaults to the max XCode version. We use now XCode 14.2 after the upgrade we will use XCode 15.2 unless we add: |
|
Small note: It's capitalized "Xcode", not "XCode" :D
Not necessarily. In general, building with a newer SDK/Xcode without bumping the requirements should usually if not always be fine. For the App Store Apple even requires using the newest one IIRC. Due to ABI stability, the binary should still run on whichever macOS version our deployment target is set to, which in practice likely means we're bound to the oldest macOS version supported by Qt. Building with a newer compiler also has the advantage that we get better C++20/23 support, so the only1 reason to build on an older macOS would be making sure that our build wasn't misconfigured somewhere (e.g. some dependency not built against the older deployment target). My impression is that most devs on macOS are usually on the latest version anyway, so this likely doesn't really impact contributors much. Footnotes
|
|
This is already in our mixxxdj/mixxx repository and notarization works. Does it mean we do not suffer the cited bug and we can just merge it? |
|
Might be the case, I'm not really sure when this happens exactly, so we'll likely only find out after running the CI workflow on the new OS a bunch of times. We'll have to do it anyway eventually though, so I don't really see this as risky. |
|
I'm not fully familiar with the implications around the minimum deployment target implications, but I was under the impression that it should not depend on the runner OS. Thanks @fwcd for sharing your insight here. If it does not affect the target, I would really like to bump the macOS version as high as possible because macOS is usually the target with the oldest compiler anyway. |
|
I think there is some merit to not using the latest runner, since we'll likely have few contributors using them and thus (if the build is misconfigured), we may unintentionally break backwards compatibility if we forget to set the deployment target somewhere. Maybe a more contrived option, but perhaps we could build on the newest macOS and then run the test suite on the older OS? Not sure if that would impose too much overhead though. |
|
If, we have a runner to check backwards compatibility, we can IMHO use it right away, there is less risk that such a binary will crash after updating. That is the reason why we normally use the oldest runner. The bump here is OK, because the macos-12 runner will likely retired during 2.6-beta and this way we avoid a runner bump during beta. I remember some incidences where a runner update broke our CI. Our CI is already quite "expensive" and has a certain CO² foodprint, so we should use it deliberately. |
|
Thanks |
|
Sh... we need probably revert: |
|
This is the bug I mentioned. We'll have to fix it anyway at some point, since the macos-12 runners likely won't be supported for that long either. |
|
The issue seems to be that macOS's antivirus (XProtect) scans the disk image, which causes a race condition with CPack. The two main workarounds are killing the XProtect process (which is still a bit brittle, since it automatically relaunches) and simply rerunning CPack a few times until it succeeds. Neither of them are particularly elegant, but they seem to work "well enough" in practice, at least when used together. If nothing else works, we could also package Mixxx as zip or tarball, but at least for the releases it would be nice to have a dmg, for consistency and to avoid having to hack around this in packages (e.g. Homebrew). |
|
Both measures sounds like a workaround not a solution. Is there a ignore list or such that we can configure to not do the scan during Cpack? In general we need an estimate how long a proper upstream solution will take and how stable our workaround is. For now it seems to be more stable to revert main and test possible solutions on the https://github.com/mixxxdj/mixxx/tree/chore/upgrade-macos13-xcode15.2 branch. Is that OK? |
|
Works for me! Admittedly I haven't looked into what upstream has been doing, but I do believe it's still a CPack bug |
Sure... Though I wonder why this didn't happen before. explicitly pushed this branch upstream so the codesign CI would run... I guess the failure is spontaneous? |
|
Done 1dc2119 |
It's a race condition, so it only happens sometimes. That's why retrying CPack is one of the workarounds. |
|
Ah right, yeah... |
|
We need to revive this soon! |
|
This looks like a Homebrew message, not a deprecation from GitHub. It just means, they won't provide prebuilt packages (bottles) anymore, so our CI workflows will likely take longer as they have to build dependencies from scratch. They should still work though. I agree that we'll have to revisit this, sooner or later, anyway though. |
MacOS 14 is also already available. Updating from 12 to 13 should give us a nice boost in C++20 compatibility on MacOS.