Cocoapods doesn't play nicely with Xcode Bots.

10180 views
Skip to first unread message

Nicolas Goles Domic

unread,
Aug 20, 2013, 12:09:52 PM8/20/13
to coco...@googlegroups.com
Hey Guys,

I was wondering if you have filled radars on this?  The problem is that without pre/post bot integrate actions, cocoapods will remain more or less unusable with Xcode Bots.

There's a radar that you can take a look at in Open Radar, and I hope that more of you guys fill radars like that one.

I see this as important to the guys that want to migrate from Jenkins to a more native C.I environment (which bots provide), and want to keep using CocoaPods without having to push the .xcworkspace and the dependencies into their git repos.

Cheers.

Michele Titolo

unread,
Aug 20, 2013, 2:46:56 PM8/20/13
to coco...@googlegroups.com
Hi Nicolas,

I've been working with Apple on a few radars related to CocoaPods and Bots. Here's the status:

1. If you check in your Pods folder, you have nothing to worry about. As long as you specify the workspace in the Bot configuration, you can build. But this isn't always the best thing, esp if you don't want to check in your .xcworkspace (I do check that in, but not the Pods folder).

2. Pre-action build steps are the only option for loading CocoaPods with Bots at the moment (when you don't check in your Pods folder and have your .xcworkspace under version control). That being said, they are kind of broken. There are issues with scheme dependencies that will "stop" a build when workspace contents change. Radars listed on the Preview Dev Forums[1]. The important one to dupe is "Build stopped when workspace contents change & Find Implicit Dependencies is on".

3. Running Ruby from pre-actions is a bitch, but can be done. I managed to figure out how to get it working though[2]. I'm assuming pre/post bot build actions would have a similar problem.

4. Pre-action failures cannot prevent the build from continuing. Currently working on a new bug report for that.

5. The bug report I filed for pre/post actions you mentioned has been duped to #14148656 which is currently listed as Open. I'd love to get a peek at exactly what that one looks like, or if there's been any back and forth.


So, yes, many radars have been filed on this. It's something I've been looking at since WWDC, but it does not appear that any significant progress has been made on Apple's end to have Bots be robust and feature-rich enough to take the place of Jenkins, or any other CI solution devs may be using.

Somewhat related, at WWDC I talked with one of the Xcode Engineers. He mentioned that Bots and Xctest weren't geared towards developers who already do CI and testing, but at those who didn't. I do not expect a decent CI option from Apple for at least another Xcode major release based on that conversation (so think years). I'd love for someone at Apple to prove me wrong.

Lastly, please dupe! I'm not sure if that actually does anything, but at least it feels like we are doing something. I was half tempted to write a radar at one point that was simply "Go see how normal engineers use non-Apple dev tools", especially because none of the engineers I talked to during WWDC Labs had ever used CocoaPods, and most had only heard of it recently, let alone any of the 3rd party testing frameworks. So it'll take them a while inside their bubble to figure out what to do, I guess.

Cheers,
Michele

Ben Scheirman

unread,
Aug 20, 2013, 2:51:41 PM8/20/13
to coco...@googlegroups.com
Michele, this is an awesomely helpful reply.  I'll be duping these radars to help raise the awareness (within Apple) that people actually use this stuff.  High five!

-- Ben
--
You received this message because you are subscribed to the Google Groups "CocoaPods" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cocoapods+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Nicolas Goles Domic

unread,
Aug 20, 2013, 4:03:05 PM8/20/13
to coco...@googlegroups.com, b...@scheirman.com
Michele,

I hope that this situation improves, I agree on that we need duplicates, you can just duplicate the Open Radar issue that I posted, which seems to be well made.

I kinda' like travis, but it's a paid solution if you're not doing open source, which leaves me with Jenkins which is a PITA to configure etc. It seems that Apple would really benefit on checking out how real engineers are using CI.

Bottom line,

Maybe I should just start using Jenkins ? What do you think?

Cheers,
Nicolas.

Nicolas Goles Domic

unread,
Aug 20, 2013, 4:19:26 PM8/20/13
to coco...@googlegroups.com
Michele in radar,

You mention a sample project that you have attached... could you upload that sample project as an attachment here so that we can duplicate this issues?

I think that we need to be quite vocal about this stuff,
I've spent so much time on this, I'm very disappointed by bots, etc.

Cheers.

Ben Scheirman

unread,
Aug 20, 2013, 4:22:40 PM8/20/13
to coco...@googlegroups.com
Related:  I just gave this talk about how to automate iOS related stuff to CocoaConf Portland last week… https://speakerdeck.com/subdigital/ios-build-automation-with-jenkins

Might be of use if you're considering Jenkins.

-- 
Ben Scheirman

Message has been deleted

Michele Titolo

unread,
Aug 20, 2013, 5:27:57 PM8/20/13
to coco...@googlegroups.com, b...@scheirman.com
Thanks for the link Ben! Getting Jenkins setup is kind of a pain, but totally worth it once you do. We just copy projects on our build machine now instead of creating things from scratch. The new Xcode 5 provisioning stuff is a pain though, so we still have 4.6 selected for xcodebuild.

Nicolas - the project I submitted to Apple is actually open source on GitHub: https://github.com/mtitolo/cats (you don't need an Instagram API key to build, but you do to run). I just pushed the comments I sent to Apple with the pre-action build step for the Bots scheme because it's kind of a pain. It does require iOS 7 and Xcode 5.

Cheers,
Michele

Nicolas Goles Domic

unread,
Aug 20, 2013, 10:56:19 PM8/20/13
to coco...@googlegroups.com, b...@scheirman.com
Hey Michele,

Thanks, will create the duplicate radars... I'm so tired of trying to play the 'Apple Standard Way' and failing in the process...

Been working on iOS 7 since day 1 now, and it's been hell... everywhere, from Bots, to crazy bugs, etc.

Cheers!
Nico.

Kra Larivain

unread,
Oct 23, 2013, 6:44:18 AM10/23/13
to coco...@googlegroups.com
Hey,

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"
cd ${SRCROOT}
rm ./Podfile.lock
rm -rf ./Pods
sudo chown -R BUILD_USER .
sudo -H -u BUILD_USER pod install
sudo chown -R _teamsserver .
fi

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).

Michele Titolo

unread,
Oct 23, 2013, 1:23:50 PM10/23/13
to coco...@googlegroups.com
Hey Kra,

Thanks for this! One question: Does this changed the resolved versions in the Podfile.lock? That's something we want to make sure doesn't change.

Also, does this work locally when you're doing a normal build in Xcode 5?

Michele

martin jacala

unread,
Oct 23, 2013, 1:29:03 PM10/23/13
to coco...@googlegroups.com
I tried to follow the guide, bud failed miserably...

running pod install as part of CI build rm: ./Podfile.lock: No such file or directory shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: Permission denied job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: Permission denied /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface/error_report.rb:91:in `chdir': Permission denied - getcwd (Errno::EACCES) from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface/error_report.rb:91:in `block in repo_information' from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface/error_report.rb:89:in `map' from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface/error_report.rb:89:in `repo_information' from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/user_interface/error_report.rb:33:in `report' from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/command.rb:61:in `report_error' from /Library/Ruby/Gems/2.0.0/gems/claide-0.3.2/lib/claide/command.rb:216:in `rescue in run' from /Library/Ruby/Gems/2.0.0/gems/claide-0.3.2/lib/claide/command.rb:204:in `run' from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/lib/cocoapods/command.rb:51:in `run' from /Library/Ruby/Gems/2.0.0/gems/cocoapods-0.26.2/bin/pod:19:in `<top (required)>' from /usr/bin/pod:23:in `load' from /usr/bin/pod:23:in `<main>'

Michele Titolo

unread,
Oct 23, 2013, 3:43:42 PM10/23/13
to coco...@googlegroups.com
You might have to adjust the paths depending on where the file is on the system. Usually Podfile.lock is in the same directory as your Podfile

martin jacala

unread,
Oct 24, 2013, 8:39:16 AM10/24/13
to coco...@googlegroups.com
i fixed the issue by adding my build user into _teamsserver group.

Alexander Deutsch

unread,
Oct 24, 2013, 9:37:21 AM10/24/13
to coco...@googlegroups.com
Hey guys,

im trying to build any workspace, but my Xcode bot is always stuck at this point:

xcodebuild: error: No destinations were specified with the -destination flag which allow the archive action.

does anyone know about this error ?

thanks

Mike Murray

unread,
Oct 24, 2013, 7:54:22 PM10/24/13
to coco...@googlegroups.com
Hey Martin, I'm seeing the same issue you were but I'm having trouble figuring out how to add my build user to the _teamsserver group. If you don't mind, could you explain how you went about it? 

Kra Larivain

unread,
Oct 25, 2013, 3:28:57 AM10/25/13
to coco...@googlegroups.com
My apologies, I had forgotten to document one step: /Library/Server/Xcode/Data is set to be rw by the _teamsserver user only. Group and world have respectively read and no access, so adding your build user to the group won’t do you any good.
This is where the bots check out the projects, if you don’t have access on a parent folder, the OS won’t grant you permission, and getcwd will fail, hence the stack trace you were getting.
Anyway, since I’m suspecting Server will reset the permissions occasionally, I’m updating the permission in the pre action, a simple chmod 777 /Library/Server/Xcode/Data does the trick.
Somewhat of a headache.

Also worth noting: I tried to gitignore the .xccheckout files, that caused the builds to fail.

Updated script:
if [ `whoami` = '_teamsserver' ]; then
echo "running pod install as part of CI build"
chmod 777 /Library/Server/Xcode/Data
cd ${SRCROOT}
rm ./Podfile.lock
rm -rf ./Pods
sudo chown -R build .
sudo -H -u build pod install
sudo chown -R _teamsserver .
fi

Overall, I’m seeing a bunch of whacky behaviors. A force push seems to make bots unhappy, changes to .xccheckout files too and I’m getting some random errors at times. It all seems super fragile to me, I’m hoping I can get it to work somewhat reliably - dashboards and Xcode integration are really nice.

@Michele: I’m personally using the pod install method so I’m blowing away the Podfile.lock and the Pods/ folder, that should ensure that the pods are always updated.

/kra
Message has been deleted

Andrew Theis

unread,
Oct 25, 2013, 2:26:57 PM10/25/13
to coco...@googlegroups.com
Hi Kra,

The reason it doesn't work on clean installs is because the Pods.xcconfig file is not present when the workspace/project is initially loaded, so the various search paths and environment variables set there are missing initially. I'm working on figuring out a way to set these again manually, but haven't found a solution yet.

Regards,

Andrew Theis

Victoria Congnan Zheng

unread,
Oct 28, 2013, 3:30:13 PM10/28/13
to coco...@googlegroups.com
Hi Kra,
Have you ever gotten error message says "the file pods.xcconfig couldn't be opened because its path couldn't be resolved"?
I kept getting this error and cannot really figure out what's going on. I had to make some changes to your script, but I believe my pods libraries are installed fine according to the logs.

Thanks,
Victoria

Eloy Durán

unread,
Oct 29, 2013, 11:55:14 AM10/29/13
to coco...@googlegroups.com
Regarding installing the gems, I have no experience with OS X Server and Xcode Bots, but normally you can also gems in, for instance, the home directory with the following env variables:

export GEM_HOME=$HOME/gems
export PATH=$GEM_HOME/bin:$PATH

Eric Johnson

unread,
Oct 31, 2013, 5:28:50 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
I've been having the same issue with xcconfig files not found/path not resolved, though it is only happening for me when the bot is configured to do multiple tasks (Analyze and Archive in my case, I don't have any tests). When the bot is configured to run just one task, it always works (save for the initial build for Archive, but all subsequent builds work. I'm guess for the reason Andrew Theis stated). I'm trying to investigate why multiple tasks seems to throw it for a loop as I don't want to keep separate bots for each task (though I guess it could work for me). Logs also show that pods are being installed correctly and the xcconfigs are all where they should be.

On another note, I do have Find Implicit Dependencies turned on, but still have my Pods target explicitly added (likely negating Find Implicit Dependencies, but I don't know enough about it to be sure).

Kra Larivain

unread,
Oct 31, 2013, 6:12:35 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
I’m having random build failures these days, though not many. The failures are in the linking phase, where the libPods is not found. I’m suspecting the pod install thing is not that reliable, so I’ll give the pod update method a try.

@Victoria: I remember running into this a few times but don’t quite remember what I did to fix it - my current setup never ran into this error though.

/kra

Michele Titolo

unread,
Oct 31, 2013, 6:46:31 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
@kra The "random failures" are likely the Pods project not finishing being compiled before the main project is. This is what the Parallelize Build setting allows, so things are not built in any specific order.

Kra Larivain

unread,
Oct 31, 2013, 6:49:07 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
Yeah, but I have "find implicit dependency" turned on, so I assume Xcode should be clever enough to wait for the Pods project to be built before it tries to link it with the app.
Never had a problem with the “standalone” Xcode. One of the problems with bots is that the logs are so verbose, they might have been an error elsewhere in the pods project causing libPods to not be available, and the reported error is not the relevant one.
I’ll play with pod update some more, see if I can get it to be more stable.

/kra

Eric Johnson

unread,
Oct 31, 2013, 7:52:14 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
With my setup I have parallel builds off, find implicit dependency on (with pod target explicitly added), and a bunch of extra logging in my pre-action and during some extra runscript build phases. I'm with you on the logs being so verbose, it started giving me a headache going through everything after every change I'd try. But from what I can tell, when I have some 'random failures' it is only with multiple actions. In those circumstances, the log at least looks like its correctly building everything in the right order, then 'randomly' PODS_ROOT will decide to not be set for one of the actions (usually Archive for me), which does lend itself to a race condition. At that point I started going in circles and just ran a whole bunch of integrations that I'll dive into tomorrow after some advil.

Michele Titolo

unread,
Oct 31, 2013, 7:54:20 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
Xcode is not that smart. You should know that by now ;)

Kra Larivain

unread,
Oct 31, 2013, 8:04:58 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
Indeed, I should know better than have faith in Xcode :)

More seriously though - I’m quite sure Xcode is clever enough to see that if you’re linking with libPods, libPods has to be built by the time you link the app. It does it when you build the project from the UI.
What I’m thinking might be happening is the pod install step screws up the project’s environment variables (or something among those lines) in very subtle ways.

@Eric: I’ve seen odd behavior with multiple actions too. My libraries have no problems running analyze + unit tests, but I never got that to work reliably on the app (analyze + KIF tests). I was planning on breaking it down into a bunch of bots anyway (analyze + iOS 7 iPhone test + iOS 6 iPhone test + iPad tests), so it’s not that much an issue for me.

/kra

Eric describing “PODS_ROOT” not being set makes sense in this theory, and it ties back to your radars reported where Xcode behaved erratically when running pod install

Victoria Zheng

unread,
Oct 31, 2013, 8:20:05 PM10/31/13
to coco...@googlegroups.com, victor...@gmail.com
@Kra,
Yeah I was able to get rid of the "pods.xcconfig couldn't be opened" error by not removing Pods folder every time. I only call pod install and pod update and it seems to be working fine. Every first build for a new bot is always a failure since it needs to pull the Pods folder from git, but I guess I'm okay with that for now.

Victoria


On Thursday, October 31, 2013 3:12:35 PM UTC-7, Kra Larivain wrote:

Ed Gueiros

unread,
Feb 21, 2014, 12:27:18 PM2/21/14
to coco...@googlegroups.com
Hi Everyone, 

I'm new to CI and I've been getting the same problems as you. This thread is from August 2013...can anyone tell me if there has been progress on this issue? If you have to give up Pods, what other solutions have you gone with? Git Submodules, just not using Pods...?

Please let me know and thank you for you help!

Michele Titolo

unread,
Feb 21, 2014, 1:34:03 PM2/21/14
to coco...@googlegroups.com
We've been keeping track of progress on the Blog repo, so we can post about it once we figure out the ideal solution: https://github.com/CocoaPods/blog.cocoapods.org/issues/21

If you have anything to add, please do so there.
Reply all
Reply to author
Forward
0 new messages