Why do we want this?
We’re using a Mac Mini as a build server here at Loot for a couple of reasons:
- To give a status of the repo/iOS project that the whole company can see
- Weekly uploads to TestFlight
So ultimately, transparency. Everyone at Loot can look at the status of our iOS app — whether they’re technical or not — at any point by going to the Xcode Server web page. They’ll also be able to download the week’s changes/improvements/fixes at the end of every week.
We also use Carthage. Having a dependency manager is important to me, if not the whole team. As the team grows, managing the different frameworks we use, maintaining docs on which versions of those frameworks we use and why we use them, gets pretty hard. Having a dependency manager makes this easier, and Carthage is our weapon of choice because it’s so simple:
- Spec the framework and version you want in the Cartfile
- Comment on line above on why we’re using this framework
- drag and drop compiled
.frameworkinto Xcode (only have to do this once)
Using Carthage also means we’re more inclined to modularise our application better because including these modules is easy. This also pushes us towards open sourcing parts of our application, like Stargate, as much as we can. OSS .
Setting up Mac OS X Server with Xcode was easy by following this post by Keith Harrison.
Homebrew is easiest. For those who haven’t used Homebrew, you should. It’s a fricking awesome, super easy way to install packages/programs. It’s just like
gem to Ruby.
All you need to do is
brew update then
brew install carthage.
When you’ve got Carthage installed, you just need to add
carthage bootstrap to the pre-trigger of your bots, and you’ll be good to go…
Here are the problems that I ran in to:
carthage bootstrapin the correct directory
- Some of our dependencies having an incorrect code signing identity
- Signing keys not being found by
carthage bootstrap in the correct directory
Your Xcode bot will clone your repo and stick it in a directory. The commands you add to your pre-triggers will start in a directory that contains this new directory which contains the cloned repo. So all you need to do is
cd into the directory containing your repo.
But what’s the name of the directory that your repo’s been put in? For now, I’ve just run the bot once with
ls -la in the pre-trigger to find out the name, and then change the
ls -la command to a
cd __FOUND_DIR_NAME__. I don’t like this solution, and I hope there are some environment variable that I can use. Please message me if you know a better way. If I find one, I will update this post.
I’d recommend making a script for any other triggers that you make and execute them from the bot’s trigger. It’d look something like this:
This way you can version control the script and edit it from anywhere. Unless your Mac OS X Server has got an external static IP address, you’ll only be able to edit your bots when you’re on the same network that the server is on. Where as by making and tracking a trigger script in your repo, it will be downloaded and executed by the bot each time the bot integrates.
Some of our dependencies having incorrect code signing identity
When you make a new framework project in Xcode 6.3.2 (current version as of writing this) the
Code Signing Identity for the
Release configuration is set to
iOS Developer. It’s pretty easy for the developer of the framework to leave this setting at its default. This may lead to signing problems for the people that use it.
To begin with, I only put our Distribution Signing Cert on the Mac Mini, so when Carthage cloned and built one of the frameworks we’re using that had this problem, the build failed explaining that it could do find a signing identity. I scratched my head for a while as I tried to work out why it wasn’t picking up the signing cert that I had definitely put on there.
If you run in to this issue, make sure that the frameworks you’re using don’t have their
Distribution Signing Identity set to
iOS Developer. The cool thing about Carthage is that it downloads and keeps the Xcode projects for the frameworks you use, so you can see the source, build configs etc. at any time.
Signing keys not being found by
This was the trickiest problem to solve.
You should need both your developer and distribution signing certificates (and their keys, of course) on your server. This is because your Xcode scheme should (and by default) have
Run to build with
Initially, I put our keys in the Login keychain, as I thought the server could access this whenever it wanted, what with it being unlocked when the Mac Mini logs in.
Apparently not. ╯°□°）╯︵ ┻━┻ . I found this GitHub issue but it didn’t shed much light. Googled some more. Nothing.
After a long while I found this post by Daniel Kennett. He dropped one massive hint in it. He said to put your Signing Keys in the System keychain..
Worked perfectly after I did this.
Here are some other things I want to set up. I’ll blog and link these soon.
- Configuring your OS X Server to send Email notifications
- Posting notifications to Slack
- Uploading to iTunes Connect/TestFlight