blog.cocoapods.org
blog.cocoapods.org copied to clipboard
CocoaPods
Post: How to use CocoaPods with Xcode CI Bots
There's also a lot of info here: https://groups.google.com/d/msg/cocoapods/eYL8QB3XjyQ/10nmCRN8YxoJ
So now we have at least 2 technique that works (and I have 1 complicated one). What is the best way to do this ? Should we write a blog post with all these techniques or prepare the gem we have discussed on the community chat?
Looks like tweets were removed, but here's a screenshot from Tweetbot. http://cl.ly/image/1y091n2l3n10
I just finished setting up builds using Xcode bots this morning for our app which uses cocoa pods, however I will say that we are going to stick with Jenkins. So far my impression of bots is that they are meant for people who have never done CI before. They are EXTREMELY limited in capability (can’t monitor a build as it’s happening, build env can’t pass parameters to the build such as build numbers, can’t run scripts pre/post build etc, can’t administer a list of people allowed to download your test app, Xcode build list not auto-refreshed when new build is run, etc).
Looks like the only thing you can do is what you can add to your build scheme, and the only feature benefit is Xcode integration (which sucks so far, was not even able to create a bot in Xcode, had to use web page) so you can link from automated test runs to source code. Neither of these warrant moving from Jenkinsish/Testflight solutions.
All that is why we are NOT converting to bots, but if you want to use cocoa pods with bots here’s what I had to do:
1 - .go through the voodoo of setting up os x server and Xcode automation - create home folder /var/teamsserver for _teamsserver user if it doesn’t already exist - make sure to set proper ownerships on /var/teamsserver to _teamsserver account
2 - add .ssh with keys that can access your local pod repo to /var/teamsserver
3 - Set up new schemes specifically for Xcode bots - edit scheme / build / pre-action add a bash script (or other script, your choice) that does something like if ~/.cocoapods/repos/localrepo does not exist, pod repo add your local repo if Pods folder does not exist pod install, else pod update - share and check in the scheme
4 - Go http://yourserver/xcode and create the bot. - create bots via xcode server web page… Xcode never let’s you get past authentication settings even when it shows them correct (this may be because we don’t allow HTTP urls on our github server, only ssh, so our url looks like [email protected]:Team/App)
Fairly short list of steps, but OS X server docs were no help at all.
I’m really hoping this is just the starting point for bots, and that they will get a lot better in the future. Currently, even though jenkins is a much more complex CI server, I found myself pulling my hair out less setting up Jenkins than I did Xcode bots. Jenkins also supports something called a config matrix so you can run multiple build configs on a single checkout.
On Nov 7, 2013, at 5:05 PM, Michele [email protected] wrote:
Looks like tweets were removed, but here's a screenshot from Tweetbot. http://cl.ly/image/1y091n2l3n10
— Reply to this email directly or view it on GitHub.
Thanks @amccarri for the detailed report! Much appreciated. What about server's ability to run your tests on multiple devices? Isn't that enough to justify it over Jenkins?
I also took the Xcode bots for a test spin. I went a slightly different direction than @amccarri in my setup:
Rather than creating a home directory at /var/teamsserver, I overrode the CP_HOME_DIR and CP_REPOS_DIR environment variables to point to a location inside the build path based off of PROJECT_ROOT (there are a bunch of environment variables configured by the build so there are options about where to put things).
If your project contains private pods (I have a private pod repository), then you wind up needing to do double configuration of your SSH access. This is because the Xcode bots walk you through setting up an RSA key to clone your code, but that configuration is never exposed to the build once it begins. So you have to configure secured Git access separately from secured Pod access. This also applies for public Pods if you pull from Github via SSH instead of via HTTPS.
Another irritating wrinkle is that you need to use a globally accessible Ruby installation for CocoaPods. If you are working off of the system Ruby and have done sudo installations of CocoaPods then it will work. But it’s pretty common (and often advisable) to see RVM or rbenv used to install parallel copies of Ruby. If you have these installed into your home directory and expect to use the same bits, then you are SOL. I went with an rbenv installation of Ruby into /usr/local/var/rbenv
I also have Bundler managing some additional dependencies necessary for my build, so I wound up having to install the bundler dependencies into a path under the build directory.
All of this required setting up pre build scripts on a Shared scheme, then pushing it remotely and testing, which was extremely slow and painful to work through.
The build output also did not update until the build had failed, so there’s a lot of dead time waiting. Then once it was all set up, the feedback mechanisms were limited and it felt very much like a bunch of trouble for very little payoff when compared to Travis CI Pro or Jenkins.
As to the ability to run tests on multiple devices:
I am not convinced that there's actually any benefit in this over running your test suite across multiple versions of the Simulator. I've done tons of automated testing and CI on iOS over the last couple of years and the types of issues that we uncover on manual on-device testing are problems that are related to concurrency, unexpected user behaviors, and performance. The concurrency and user behavior problems won't become visible just because you run your suite on a device instead of the simulator and performance issues are typically perceputal -- a view "feels sluggish" or laggy. These kinds of conditions aren't testable in an automated way. There is also a major performance penalty to running your tests on real hardware. They are going to run much slower as you have slower processors, less memory, and less I/O throughput. The slower they are to execute, the lower your iteration throughput and the less you can lean on CI. So what's the benefit over the simulator?
After giving CI bots a thorough tire-kicking, I ultimately went back to Jenkins and haven't looked back. My Jenkins setup is simpler and much more powerful/flexible. Hope this saves someone some wasted hours.
Not unique to bots, you can do this with jenkins or any other CI tool that can run a command line build. From the xcodebuild man page:
xcodebuild -workspace MyWorkspace.xcworkspace -scheme MyScheme -destination 'platform=iOS Simulator,name=iPhone' -destination 'platform=iOS,name=My iPad' test
I created a blog post out of my original email that includes a sample script for my bots config, can find it here:
http://alexlikescode.blogspot.com
On Nov 10, 2013, at 4:14 AM, Markos Charatzas [email protected] wrote:
Thanks @amccarri for the detailed report! Much appreciated. What about server's ability to run your tests on multiple devices? Isn't that enough to justify it over Jenkins?
— Reply to this email directly or view it on GitHub.
@blakewatters thanks for the info! What kind of advantage do you see with the environment variables instead of the folder in /var/teamsserver? Do you think this approach would be more robust and possibly future-proof for updates?
@amccarri We already have instructions for other CI systems. This post will be specifically on Bots because so many people have asked about them. This isn't saying we recommend using Bots, but we should provide instructions on how to use cocoapods with them since Apple will likely push people to use them.
@mtitolo sorry should have directed my comment, @qnoid was asking about bots' ability to run tests on multiple devices as an advantage over other solutions. I was just pointing out that running tests on multiple devices is not necessarily a feature of bots, but rather a feature of xcodebuild which can be used anywhere.
Oh btw, here's my build pre-action script for using cocoa pods with bots:
cd $SRCROOT
if [ ! -e "$HOME/.cocoapods/repos/OurRepo" ]
then
pod repo add OurRepo git@ourgithub:OurApps/CocoaPodSpecs.git
fi
if [ -e "Pods" ]
then
pod update
else
pod install
fi
It still needs to happen. I haven't had the time to actually write the post and double check all of the solutions.
@swizzlr if you want to be useful, you could try one of the solutions listed above.
Thanks @amccarri, your experience really helped me.
Mac OS X 10.9.2, Xcode 5.1b5, CocoaPods 0.29.0
I created /var/teamsserver and set it's owner to _teamsserver.
I created a scheme pre-action script:
export PATH=/usr/local/opt/ruby/bin:/usr/local/bin:$PATH
brew update
brew upgrade
gem update --system
gem update cocoa pods
cd ${SRCROOT}
if [ -e "Pods" ]
then
pod update
else
pod install
fi
It's working flawlessly. As a two-step set-up procedure, I'd say this is really not a problem.
Alex, thank you for summarizing that. I'll see if I can try wrapping it into a cp plugin.
Starting to work on the blog post for this. Comments welcome - https://github.com/CocoaPods/blog.cocoapods.org/blob/master/_drafts/CocoaPods-Bots.markdown
This won't use any of the plugins (which may or may not work with Server anyway).
That's great work everyone. I have all my builds compiling and my tests passing. I have, however, one error in my 'Analyze' phase. === ANALYZE TARGET CI_TestProject OF PROJECT CI_TestProject WITH CONFIGURATION Debug === ld: library not found for -lPods clang: error: linker command failed with exit code 1 (use -v to see invocation)
Everything else is great. Pre-script is run, pods are installed and linked. But Analyze seems to be the very first thing that runs, and I get that error. Any pointers? Thanks in advance!
@egueiros not sure if this applies to your case. Check Build Active Architecture Only. In my case Pods project had Build Active Architecture Only set to YES for Debug builds, but in the main project it was set to NO. Changing Pods project flag to NO fixed the problem.
And another blog post for reference: http://chris.cm/setting-up-xcode-bots-with-cocoapods/
@moayes You should normally change it on your project to YES, not set it to NO on the Pods project.
I hacked something but right now i'm getting error when building some of static lib, locally everything is working fine :/:
The following build commands failed:
CompileC /Library/Server/Xcode/Data/BotRuns/Cache/2ab22af0-2cb0-4b18-ac23-4e5edb40d808/DerivedData/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SDWebImage.build/Objects-normal/i386/NSData+ImageContentType.o SDWebImage/SDWebImage/NSData+ImageContentType.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)
Additionaly if i uncheck find implicit dependencies on shared target i'm getting
ld: library not found for -lPods
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Update #1: Everything working on Debug (XCode), but when i changed target to release, it says that: ld: library not found for -lPods
@egueiros & @m1entus: I have the same problem:
ld: library not found for -lPods
Did you find any solution?
@MatejBalantic Ok solved, problem was that i was using pre-build script which was propably called for every tharget in cocoapods, i debug it in Jenkins (lol) :) I solved it by adding additional static library target, my solution here: https://gist.github.com/m1entus/9660734
@m1entus sorry but your solution is unclear to me. I just recently started getting the same issue as @egueiros and @MatejBalantic. Could you maybe describe the steps in more detail? Thanks!
