Now that mavericks is officially out, I’ve been playing with this.
I gotta say, it’s a quite a pain to get working the first time, though I kind of got it working for unit testing and analyze. I’m not interested in archives, so I haven’t tested that, I assume it should work equally.
The biggest issue I’ve run into is that the build runs on the bot as an unprivileged user with no shell (_teamsserver with /usr/bin/false as a shell). If you run pod update as this user, there’s no way you can get it to work. I worked around that with some sudo wizardry in my pre action.
The second issue is that I could not get the build to go through when I enable a full clean before each integration. Xcode freaks out, doesn’t put the libPods in the build folder, and lib tool then complains (duh).
I got it to work with a pod install, i.e. no Podfile.lock nor Pods folder checked in. A pod update, i.e. a Podfile.lock checked in, but no Pods folder worked too.
Of course, I had to add a pre action to get that working, though there are a few hoops to jump through.
Anyway, what I’ve figured out so far:
- check your .xcworkspace in source control. check the Podfile.lock if you to walk down the pod update path.
- add _teamsserver to the password-less sudoers (%_teamsserver ALL=(ALL) NOPASSWD: ALL in your sudoers file). You probably want to be a little bit more clever and only grant it sudo privilege for the pod command :)
- add to your pre action the following script, where BUILD_USER is your, well, build user. Make sure you “Provide build settings from” the main target, SRCROOT won’t be set otherwise (the default is “None”).
if [ `whoami` = '_teamsserver' ]; then
echo "running pod install as part of CI build"
rm -rf ./Pods
sudo chown -R BUILD_USER .
sudo -H -u BUILD_USER pod install
sudo chown -R _teamsserver .
It’s not rocket science:
give permission to the build user on the current folder, clean the mess left from the previous build, run pod install as the build user and finally give ownership back to the _teamsserver user. You want to skip this when not in a CI context, hence the check on the user.
So far, I have a library pod getting unit tested and analyzed, and an app getting tested with KIF, seems to be working fine (knock on wood).
Now, I have no idea why running a full clean causes the build to fail, and it makes me think it’s not a good idea to use bots + cocoapods for production builds yet, since there might be some files left over from previous builds, though there probably is a solution to that problem (crossing fingers).