With Xcode 6 GM coming out this week we couldn’t wait anymore and so pushed support for Xcode 6 into production.
Now you should be able to compile and test your projects with iOS 8 SDK, including code written on Swift.
For now however Xcode 6 is still marked as beta, so you have to enable it explicitly by selecting iOS 8 SDK when configuring your project targets:
That’s all, after you save project settings new builds would use iOS 8 SDK. Please contact us at firstname.lastname@example.org if you have any problems / questions.
As some of you may have noticed – all of the newly created / updated projects on Hosted CI use xctool with custom shell scripts in build process,
instead of relying on Xcode plugin for Jenkins as before.
There are several important reasons for this change:
Jenkins plugin is inflexible and hard to make changes to. One has to edit Java code, recompile .jpi file, deploy it to Jenkins and then restart Jenkins to make any change to the build commands used. With our own shell scripts and xctool it is just a matter of editing shell script file.
Jenkins plugin relies on using xcodebuild which produces hard to decipher output that is full of garbage. xctool has much cleaner output.
I guess you’ve already heard about terrible Heartbleed bug in OpenSSL library.
So I’m here to tell you some good news – we didn’t even have to fix it at all. :)
Our server uses OpenSSL version 0.9.8, which isn’t vulnerable to this bug. So you don’t have to change your passwords at Hosted CI, unless you have reused them on other sites. Sometimes it pays off to use conservative Linux distro like Debian.
If you have any questions or need help with Hosted CI, please write to me at email@example.com.
I’m going to WWDC this year and will stay in San Francisco from Sunday 9th of June to Friday 14th.
So if you either attend WWDC or just happen to live near – I’d like to meet to discuss Hosted CI, contiuous integration and programming in general.
Machine would never test your app better than a human person can.
So starting from today we provide an option (on Premium and Max plans)
to enable human testing of each otherwise successful Hosted CI build.
It is made possible thanks to availability of human intelligence API from Amazon Mechanical Turk service,
which we use through modified version of Jenkins Xcode Plugin.
As distributing your iOS apps to random people is quite a hassle (having to manage all those UDIDs) –
we take care of that for you. We sign your app with our own distribution certificate and use own provisioning profile,
so that you don’t have to deal with it.
Note that it means that apps using In-App Purchase and Push Notifications won’t work without modifications,
please contact our support if you need to use aforementioned functionality.
However FullContact’s solution is quite hacky and is Git-only (while we have to support Git, Mercurial and Subversion). So I had to put together my own solution which is described in this post.
Implementing separate code for each of the version control systems seemed like overkill (especially given the same info is already parsed by Jenkins). I’ve decided to fetch the commit logs using Jenkins REST API, however after further investigation I used a simpler hack.
Jenkins stores information about builds in a relatively straightforward order, which looks something like following (included only stuff relevant for our task):
+- lastSuccessful (symlink to the last successful build folder)
+- [BUILD_NUMBER] (for each build, symlink to corresponding build folder)
+- [BUILD_ID] (for each build, contains all data, named based on build date)
+- changelog.xml (this file contains change logs that we need)
Individual changelog.xml files contain data in folowing format:
Changes in branch origin/master, between b34f501dbddae6ccc962797945d44b7f37ce38f6 and d24808f7bd6c3c84ba256913350472e370cbc42e
author Vladimir Grichina <firstname.lastname@example.org> 1358642236 +0200
committer Vladimir Grichina <email@example.com> 1358642236 +0200
Added CalendarDemo as dependency for tests
:100644 100644 72f0d09be20b86ec26f19af064dddd96fc186169 be53875b416ba4c968c31b5edfe8287aded833ff M Calendar.xcodeproj/project.pbxproj
author Vladimir Grichina <firstname.lastname@example.org> 1358642075 +0200
committer Vladimir Grichina <email@example.com> 1358642075 +0200
Uncommented commented out tests
:100644 100644 1e0c797595d2b09491aa0939d4a86dd2bf5766ca 4cd227fd5b19d2a1ec80e8adb67fecdbe727fdd1 M CalendarTests/CalendarViewSpec.m
So basically our script has to do following:
Get build folder linked to by lastSuccessful symlink
Find changelog.xml files in all build folders that go after it (in lexicographical order)
Select relevant info from changelog.xml files
Output resulting message for TestFlight upload script
Most of Hosted CI code is using Node.js, so I used it for this script too (slightly adapted here to be standalone):
Now it is just needed to use it in Jenkins – I use script similar to the following:
COMMIT_LOG="Changes since last build:\n"`/path/to/script.js "$JOB_NAME"`curl http://testflightapp.com/api/builds.json \ -F file=@"$WORKSPACE/PROJECT_DIR/build/CONFIGURATION-iphoneos/TARGET_NAME-CONFIGURATION-$BUILD_NUMBER.ipa"\ -F api_token="API_TOKEN" -F team_token="TEAM_TOKEN"\ -F notes="This is an autodeploy build $BUILD_ID from http://hosted-ci.com\n\n$COMMIT_LOG"\ -F notify=True -F distribution_lists="DISTRIBUTION_LIST"
To avoid all aforementioned pain-in-the-ass you may wish to subscribe to Hosted CI, which provides complete CI solution for iOS / Mac apps without need to waste time tinkering with Jenkins configuration.
This post duplicates our knowledge base entry here.
Code-signing of iOS apps is often quite tricky and so questions on it arise.
It is common to have situations where build on different machines needs different code-signing settings Developer may use his own iPhone Developer identity to test app on his device, however appropriate iPhone Distribution identity has to be used for “Ad-Hoc” builds sent to testers.
When using continuous integration builds it may rise the problem: if identity set in Xcode project is iPhone Developer and it is committed into source code repository – it cannot be used by build server as is.
The solution is simple. Xcode has concept of build configurations and by default two of them are available: Debug and Release.
So there are two ways to solve the problem:
Configure iPhone Developer for Debug builds and iPhone Distribution for Release builds. Then use Release configuration in CI builds.
Add configuration specific to CI build and make it use appropriate iPhone Distribution identity. Then use it in CI builds.
In both cases you’ll be able to commit Xcode project into repository and then not have to override identity for each specific build. However in first case developer still occasionally may need to alter code signing identity to debug Release builds.