Xcode 14.2 Released [Breaking Changes]

Announcements
1

The Xcode 14.2 image has been released and can be selected as follows:

macos:
    xcode: 14.2.0

:rotating_light: This image includes some breaking changes :rotating_light:

In an effort to align our macOS images with our Linux and Windows offerings, we have been working on a new image build system which is now in production. This change also affects some software packages in the macOS images moving forward.

Here are the main changes:

  • Ruby management has changed from chruby to rbenv
    • Ruby 3.0 remains the default Ruby
    • We continue to install the latest patch versions of currently maintained rubies
    • We recommend using the macOS Orb to switch Ruby versions. This has been updated to include rbenv support. Ensure you are using Orb version 2.3.3, or have pinned your Orb version to @2
  • Python is now managed by pyenv
    • We will install the latest version of Python at the time of the image build
    • Python remains accessible via python3 and pip3
  • Java is now installed with Temurin
    • We always install the latest LTS release

If you run into any unexpected behaviour, or any other problems, upgrading your pipelines to this image, please let us know in this thread, or by reaching out to support.

:information_source: VM Image Info :information_source:

Xcode 14.2 Build version 14C18 is installed at /Applications/Xcode-14.2.app

The full manifest of installed software can be found here

Update: As the Release version of Xcode 14.2 and the RC version have identical build numbers, we do not need to build a new image for the Release version :slight_smile:

2

FYI that I’m seeing an error with yarn install on Xcode 14.2 images, that wasn’t present on Xcode 14.1 images. More details in this post.

3

Hi @jpeckner Looks like we missed this package in the migration to the new image builder. We will see if we can retroactively apply the package, but meanwhile the quickest way to resolve it is to add the following to your job

HOMEBREW_NO_AUTO_UPDATE=1 brew install yarn

This should be a fairly quick install. We will update this thread when we have a proper fix in place.

Thanks for the feedback!

4

@bytesguy Thanks for the quick reply! It’s running into a different error now when I try to cd to a different directory in my project (guess it’s not melding with brew install node for some reason). Rather than debug that, for now I’ll wait until the image has been fixed to include yarn. Let us know when that’s ready and thanks in advance :pray:

5

@jpeckner I would recommend sticking to nvm as this is already included in the image (we have been including nvm as the default node for a little while now), if you need a particular version you just need to call the nvm install command and specify the version you need - it’s pretty quick.

If you can post the error message when running a job with the HOMEBREW_NO_AUTO_UPDATE=1 brew install yarn step added that would be helpful. It may take a day or two for the fix to be applied, but meanwhile this command only takes about 5s to run so it isn’t too impactful on the job time.

(or feel free to open a support ticket if it is easier due to sensitive info in the job output)

6

I have added the ruby switch step, using the orb, and it succeeds. However, a few steps later I’m getting a ruby version error:

#!/bin/bash --login -eo pipefail
bundle config set path 'vendor/bundle'
rbenv: version `ruby-3.0.0' is not installed (set by /Users/distiller/workflow/source/.ruby-version)

Exited with code exit status 1
CircleCI received exit code 1
7

@stromdotcom looks like you have a Ruby version file checked in your repo which is trying to force Ruby version 3.0.0. In the error message this is saying it is reading the file “/Users/distiller/workflow/source/.ruby-version”

You should either remove this file or update it to match the versions that ship in the image (see the software manifest for details)

8

Thanks. Isn’t that the point of the ruby switch step though?

    - macos/switch-ruby:
        version: "3.0"

This runs successfully before the job that throws that error. I want Ruby 3.0.0

9

The version in the image is 3.0.5 but rbenv itself doesn’t allow fuzzy matching, so you have to specify a patch version - your Ruby version file was requesting 3.0.0 specifically which is not equal to 3.0.5.

The orb has some logic to include fuzzy matching so you only need to specify up to the minor version, so 3.0 in the config will match to 3.0.5 in the image.

By having a Ruby version file it was overriding the default Ruby version which was set by the orb command. Local Ruby version files always take priority over globally set Ruby version in rbenv

10

We have some issues with the Xcode 14.2 image.

No matter what we do, we get these errors when running brew install mint. Also tried HOMEBREW_NO_AUTO_UPDATE=1 brew install mint.

/usr/local/Cellar/rbenv/1.2.0/libexec/rbenv-init: line 108: rbenv-commands: command not found
/usr/local/Cellar/pyenv/2.3.7/libexec/pyenv-init: line 228: pyenv-commands: command not found

What we have tried:

  • Using the macOS orb to set ruby version (3.0.5 and 2.7.7, both already installed)
  • Not setting a ruby version at all, just use what’s default (3.0.5)
  • Manually setting the ruby version (docs not updated with how to set ruby version on latest macOS image, I tried reusing code from the orb)

Any ideas what’s wrong?

We had no issues with the Xcode 13.x images. The only change we have done is changing/removing how we set ruby version (because of the breaking change)

11

Is git lfs install not run by default on the new image? Just had to add a step to run it on my workflow before checkout to get it to work. Didn’t have to do this before.

12

@LaStrada please submit a ticket to support as we will need to see your full job. I suspect something is colliding with the bash profile here

@mcahillane-ia Git lfs is installed via brew as normal. I have just tested this against 14.2.0 and the git lfs command works as expected

Screenshot 2023-01-09 at 20.47.00
Screenshot 2023-01-09 at 20.47.001632×582 53.8 KB

13

Hey @bytesguy. Yep, I could see that it had been installed via brew, but it looks like the git lfs install had not been run.
My builds were failing because the file managed by git lfs were not present after the checkout.
Adding an explicit git lfs install before checkout fixed it.

14

@mcahillane-ia Ah got you, we will look into this. Likely this is something we can fix for the existing image soon. I will update here once it is done. Thanks for the feedback!

1 Like
15

I used the orb as suggested and set the version to 3.0.0

Even then my job failed with,
rbenv: version 'ruby-2.4' is not installed (set by /Users/distiller/.ruby-version)

The workaround for me was to add in a step command to delete /Users/distiller/.ruby-version.
Why is it so? How did the default user distiller end up with a .ruby-version file?

16

@SivaZ Ruby 3.0.0 does not exist in this image, the version in the image is 3.0.5: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v10821/manifest.txt

Please try specifying either 3.0.5 or 3.0 with the latest Orb version

17

My builds are failing and I’m trying to track down the exact problem. It appears to be missing macOS support libraries that I believe are installed by default.

Some notes up front: I am running on CircleCI only after a major change to my iOS project as I move it from CocoaPods to Swift Package Manager. On my local machine the Fastlane script will run successfully, build the project and perform the testing.

  • My machine is macOS version 13.1 & Xcode version 14.2 (14C18)
  • This release of CircleCI is macOS version 12.6 & Xcode version 14.2 (14C18)

The new project structure is based on using Swift Package Manager. One of the packages my project includes also contains SPM plugins to run a command line executable. That executable is also a Swift Package which is compiled for macOS. In other words, my project compiles and runs a macOS Swift command line executable.

When this executable runs it fails with the error:

dyld[13671]: Library not loaded: ‘/usr/lib/swift/libswift_StringProcessing.dylib’
Referenced from: ‘/Users/distiller/project/CanvasDx/DerivedData/SourcePackages/checkouts/cognoa-mac-tools/.build/x86_64-apple-macosx/debug/cbt’
Reason: tried: ‘/usr/lib/swift/libswift_StringProcessing.dylib’ (no such file), ‘/usr/local/lib/libswift_StringProcessing.dylib’ (no such file), ‘/usr/lib/libswift_StringProcessing.dylib’ (no such file)

Ordinarily when running through my workflow this executable is compiled and run by xcodebuild. I was concerned that there may have been some environment variables that could cause various paths to be wrong causing the dynamic linking error. But I was able to rule this out by building this executable directly on the CircleCI machine using swift build. I get the same error when it is run.

I searched for a libswift_StringProcessing.dylib on the CircleCI machine and only found libraries for other platforms (iOS, tvOS, watchOS, CoreSimulator, iOS.Simulator)

/Library/Developer/CoreSimulator/Volumes/watchOS_20S75/Library/Developer/CoreSimulator/Profiles/Runtimes/watchOS 9.1.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/Library/Developer/CoreSimulator/Volumes/tvOS_20K67/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS 16.1.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Library/Developer/CoreSimulator/Volumes/watchOS_20S75/Library/Developer/CoreSimulator/Profiles/Runtimes/watchOS 9.1.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Library/Developer/CoreSimulator/Volumes/tvOS_20K67/Library/Developer/CoreSimulator/Profiles/Runtimes/tvOS 16.1.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Applications/Xcode-14.2.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/Applications/Xcode-14.2.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib

My local macOS 13.1 machine includes macOS builds:

/System/Volumes/Data/Users/brian/Library/Developer/Xcode/macOS DeviceSupport/13.1 (22C65) x86_64/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.0 (20A362) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.2 (20C65) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.1.1 (20B101) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.0 (20A5356a) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.1 (20B82) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Applications/Xcode-14.1.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/System/Volumes/Data/Applications/Xcode-14.2.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/Users/brian/Library/Developer/Xcode/macOS DeviceSupport/13.1 (22C65) x86_64/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.0 (20A362) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.2 (20C65) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.1.1 (20B101) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.0 (20A5356a) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/Users/brian/Library/Developer/Xcode/iOS DeviceSupport/16.1 (20B82) arm64e/Symbols/usr/lib/swift/libswift_StringProcessing.dylib
/Applications/Xcode-14.1.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib
/Applications/Xcode-14.2.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswift_StringProcessing.dylib

I admit it is possible that the problem is that I am using a different macOS version, but I don’t expect so.

It appears that macOS device support is not download with the CircleICI Xcode install. That doesn’t make sense to me because I understand that to be included by default. There are obviously aspects to how this container is built, and how support files are installed, that I don’t understand.

Does anyone understand what might be going on?

18

Ahhh. And of course the installed software notes report runtimes of:

======== Runtimes ========
iOS 15.5
iOS 16.2
tvOS 16.1
watchOS 8.5
watchOS 9.1

Does this mean it is not possible to run a swift executable on this release? Does a macOS runtime need to be explicitly included?

One thing I didn’t mention above is that I am run a M1 MacBook pro and I am guessing the CircleCI machines are all Intel still.

19

I admit it is possible that the problem is that I am using a different macOS version, but I don’t expect so.

This does appear to be the problem. I now believe the problem is that I have included a macOS 13 only Swift language feature (regex) in this executable target. I thought that the @avalible annotations would allow the executable to compile and run on older OSs. In fact, it compiles, but Apple might not have allowed for conditionally linking to this library to allow it to run.

@bytesguy Are there plans to release a macOS 13 machine soon?

20

@briancordanyoung Yes the macOS resource class on CircleCI is currently Intel only at the moment.

The Swift version is listed in the manifest file (e.g., Swift: Apple Swift version 5.7.2).

It is entirely likely that the issue was a conflict in environments between your local setup and the remote setup in CircleCI.

I have Ventura support ready, and have for a little while now, but we have to wait for our infrastructure team to make some changes and green-light it. I am hoping this will be with the next Xcode release (which will likely require Ventura anyway), but at the moment it is a bit out of my hands unfortunately.