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.

Carthage

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:

  1. Spec the framework and version you want in the Cartfile
  2. Comment on line above on why we’re using this framework
  3. carthage bootstrap
  4. drag and drop compiled .framework into Xcode (only have to do this once)
  5. :tada:

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 :heart:.

Setting up

Setting up Mac OS X Server with Xcode was easy by following this post by Keith Harrison.

Adding Carthage

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…

NOT


Here are the problems that I ran in to:

  1. Executing carthage bootstrap in the correct directory
  2. Some of our dependencies having an incorrect code signing identity
  3. Signing keys not being found by xcodebuild

Executing 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:

cd __REPO_DIR_HERE__
./trigger-script.sh

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 xcodebuild

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 Debug configuration.

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.

SUCCESS

Next up

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