-
Notifications
You must be signed in to change notification settings - Fork 136
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
Upgrade macOS version and Xcode version for Mac machines #1431
Comments
Failing test on macOS 12.5.1: https://buildkite.com/bazel-testing/bazel-bazel/builds/8481#018330f9-71a1-4bc5-a8be-942f5c5ac3f9 |
@meteorcloudy Is there any way we can install Xcode 14? It would unblock some tests in rules_apple. #1348 (comment) |
I'm looking into it |
I'm in the process of installing both 13.4.1 and 14.2. However, some of the machines require an OS update, too. I hope that the process will be finished by tomorrow EOD. |
Hey @fweikert! Thanks for doing this. I assume the rollout has been completed but the default version hasn't been changed, so we need to add an override? I also noticed some failures starting Tuesday last week in our scheduled builds on our master branch: https://buildkite.com/bazel/rules-apple-darwin/builds?branch=master It looks like the main issue is the that the tvOS SDK isn't installed anymore. We should likely make sure that every machine has all SDKs installed (with something like |
We also realized that the we have a |
Hey, Technically our CI should now default to Xcode 14.2 on Ventura, but apparently there is a bug that I still need to find. Can you explicitly specify 14.2 in your test config? |
I guess we could (provided the tvOS simulator runtimes are installed for that specific version), but not sure what other stuff will break in our repos. |
Is there no way to specify that we want to run on Monterey? Or is the whole fleet assumed to be Xcode 14.2/Ventura now? |
It's a bit tricky right now - all the iMacs run Ventura (platform |
To elaborate a bit on the background: Right now CI fleet management is quite painful since we have to manually maintain 40 Macs of different generations (trash can Mac Pros, iMac Pros, MacStudios). We're working on virtualizing the fleet, which would allow us to offer multiple different OS versions at the same time. |
bazelbuild#1542 relied on platform.mac_ver() to detect the MacOS version, which did not work as expected. Consequently, the previous PR led the CI to activate an incorrect version of Xcode. This behavior has been fixed by this change. Related to bazelbuild#1431.
#1542 relied on platform.mac_ver() to detect the MacOS version, which did not work as expected. Consequently, the previous PR led the CI to activate an incorrect version of Xcode. This behavior has been fixed by this change. Related to #1431. Users can still request a specific Xcode version in their CI config.
We definitely have tests failing on arm64, so switching directly to Mac Studios might be tricky in the short-term. I'm seeing messages related to the simulator runtimes being a bit off on those machines as well:
I think the best path forward would making sure the simulator runtimes and SDKs are installed properly on all machines, and then we can proceed to see which option gets us back to green asap (I'm thinking Xcode 14.0 running on Ventura at the moment). |
I guess neither me or Florian is very familiar with this. Can you give some instructions on how to do this? @fweikert Can you try to run |
I think following this guide should be a good start: https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes Running |
I ran
However, |
I think that's good enough, we might not need other runtimes that are not bundled with Xcode by default (I don't think we run tests on lower iOS versions in our repos). Looks like I was able to get a rules_apple PR that switches us to Xcode 14.2 on the iMacs green now: I only noticed one issue on
It looks like the "Apple Watch Series 7 (45mm)" simulator is not correctly created. If you run |
I can see |
Looks like CI ~is~ was broken because the [CI fleet was upgraded to Xcode 14.2](bazelbuild/continuous-integration#1431 (comment)) and some machines were missing the watchOS and tvOS SDKs. Now that the iMacs are properly set up, we should be able to simply use Xcode 14.2. We can't use Xcode 13.0 anymore because it doesn't run on macOS Ventura (which all the x86_64 machines are on after the upgrade). Future tasks might include adding support for arm64 in our tooling so that we can switch to run on Mac Studios instead of iMacs.
@fweikert I'm still seeing issues with the Apple Watch simulators. If I run
Maybe since the watchOS and tvOS simulators were installed post-Xcode install, we need to create some defaults manually? |
Which machine was that? |
My latest build is here. Reproduced it on |
After some more debugging I have even more questions:
|
A simulator is used internally by Xcode for asset compilation, because it needs to run the tool "on device". |
Regarding 3, it sounds like the result is cached on following runs, so the action doesn’t even run. You should try a |
Yeah, I ran |
Regarding 2, I checked locally and I also don't see watchOS devices as separate, but they should be listed in the iOS devices and show up as "Paired Watches". |
We're continuing similar errors and this is issue is blocking several PRs that we would like to merge. A new log that is very similar to the previous one (permissions issues) can be found here: https://buildkite.com/bazel/rules-apple-darwin/builds/7156#0187c3d3-c92c-4f01-93c6-086ca39ebe7d
If the Bazel invocations outside buildkite worked fine, I suspect this is an issue in the way buildkite and it's agent's permissions are set up. Would it be possible to tweak those so we can try to get to the bottom of this? |
The permissions error looks fixable. Re other error: Any objection to upgrading to Xcode 14.3? |
I don't have any objections from my side, I'm not aware of anything that would break in 14.3. Is this upgrade to try and see if the errors are fixed in newer versions of Xcode or for some other reason? |
Both, looks like we need Xcode 14.3 for TensorFlow: #1617 |
Unfortunately upgrading to 14.3 led to other problems: bazelbuild/bazel#18278 |
looks like the back and forth might have affected the platform setup https://buildkite.com/bazel/bcr-presubmit/builds/1309#01882af9-ad72-4000-90e9-2c93f350e1d1 |
maybe a new issue too in that log:
|
With bazelbuild/bazel#17451 and bazelbuild/bazel#18460 we can hopefully switch to Xcode 14.3 again soon. |
Any news on this? We're unable to merge certain PRs in rules_apple due to this CI issue for the last 2 months. bazelbuild/rules_apple#1942 |
@fweikert @meteorcloudy Is there any way we can install Xcode 14.3 on all machines? Using it would fix the failures in the PR above and decrease flakiness. As you can see in this build, the Xcode 14.3 builds passed but not on 14.2. |
@BalestraPatrick I'm installing Xcode 14.3 on all Mac machines now. |
Xcode 14.3 should be available on all Mac machines now! |
@meteorcloudy Thank you! It looks like we also need all the new SDKs for that version: https://buildkite.com/bazel/rules-apple-darwin/builds/7734#018a035a-690b-4dde-9a93-8e392b924528 We need watchOS 9.4 and tvOS 16.4. I think running |
Let me try that |
Rerunning the command ended up with |
I got also the
And then run |
@acecilia Thanks! In the end, I got |
Did the update to 14.3 fix the problem with not being to spawn Watch 7 (45mm) devices? |
bazelbuild#1542 relied on platform.mac_ver() to detect the MacOS version, which did not work as expected. Consequently, the previous PR led the CI to activate an incorrect version of Xcode. This behavior has been fixed by this change. Related to bazelbuild#1431. Users can still request a specific Xcode version in their CI config.
This is a temporary change whose sole purpose is to allow me to target individual Macs in order to debug problems such as those outlined in bazelbuild#1431.
python
no longer available.The text was updated successfully, but these errors were encountered: