In the Xcode 6 update postmortem we mentioned that we were going to start rolling out OS X environment in a more staged approach. Today we are making the new environment available as a beta.
Our plan is to make this new image the default image in two weeks (November 17, 2014), but we may postpone that if there are any issues with the environment we haven’t been able to fix by then.
This environment update includes:
- Xcode 6.1 and the iOS 8.1 and OS X 10.10 SDK. Note that the iOS 8.0 SDK is no longer available.
- xcpretty and GCC 4.8 have been reinstalled (issue #2828 and #2892).
- xctool has been upgraded to version 0.2.1 (issue #2836).
- We’ve recompiled all Rubies against the latest Xcode and OpenSSL, and we’ve replaced 2.1.1 with 2.1.3. (2.1.4 isn’t preinstalled, but can be installed on-demand by adding
rvm: 2.1.4to the .travis.yml)
- osascript now has assistive access (issue #2846).
- The build script is now run in a TTY (issue #2872).
- The time zone is changed to UTC.
- More fixes have been added to authorize instruments.
- The “enable hardware keyboard” setting in the iOS simulator has been disabled (issue #2846).
- Update CocoaPods to 0.34.4.
To test out the new environment, add
osx_image: xcode61 to your .travis.yml. Even if your project doesn’t need any of the changes above to build, we would greatly appreciate if you could try this environment out on a branch to help uncover any issues with it.
Why did this update take so long?
We started working on this update immediately after the Xcode 6 update was out, and had an image ready on October 22nd, the same day we published our Xcode 6 postmortem. When we tested it we noticed that the image would frequently get stuck in the boot sequence, causing it to time out. We spent some time trying to localize whether this was an issue with the image itself or the virtualization setup, as well as trying to roll out the image again in case something had gone wrong the first time.
On October 30th, we discovered that only a subset of our servers were affected by this issue. We worked with our infrastructure provider and discovered that the image was being corrupted during the distribution to the servers. A workaround was found, and we’ve documented it to avoid this in future updates.