Trying to build Xcode Project, Works Locally, Fails in TeamCity

Project uses OCHamcrest. Locally, works fine using this command:

    xcodebuild clean test -workspace myProject.xcworkspace -scheme myProjectTests -destination 'platform=iOS Simulator,name=iPad'

When run in TeamCity, it fails compiling, claiming it cannot find the OCHamcrest header files.

The files are there, a find . -name command from the work directory shows them.

Fiddled with the Header search path, point it to the directory. Didn't seem to matter. Doesn't look like it constructs the commands properly. Not sure why xcode has no problem finding the headers locally.

9 comments
Comment actions Permalink

You can ssh to buildAgent machine and run the same command here, from checkoutDirectory and troubleshoot it. Most likely, it's because some environment variables or necessary libraries are missing.

0
Comment actions Permalink

Hi Sergey:

Of course I did this. Never did figure this out: the header search path for frameworks just would not make it build in TC's version of the code. I finally outsmarted it by putting the framework (OCHamcrest) into one of the system framework search path locations.

0
Comment actions Permalink

I'm not very familiar with XCode runner and its details, but assumption is that OCHamcrest is an external library that must be either put to VCS with the code or be available on the agent machine.

Please correct me if I'm wrong.

0
Comment actions Permalink

Obviously Sergey. I had all the header files in the project and the directory they were in was in the framework search path. Did not work on the server, did build locally. The local build was NOT getting the headers from one of the other directories because I moved them at one point (from the source tree to the test tree) and upon removal from the source tree, the build broke. On returning it to the project, it worked again.

This is the problem with using this product: like most products from the land where choice is king, the burden of cobbling the pieces together and trying to make them work falls on the consumer, vs. the traditional notion of a 'product' as something that was um, already assembled and tested, lol.

What would make a LOT of sense (but probably will never happen) would be for Team City to ship with examples of the most basic types of projects, that work, including an ios one, an android one, etc. Another example of how absurd the current state is: to run android tests in CI you have to run the emulator. Gradle is so broken that if the emulator has not started, it will 'run' your tests and they will all pass even though they never actually ran. So you have to wait for the emulator to load. I found a guy who did that with an adb command. Then I found that there's a plugin for the emulator. The readme file in github contains guess how much text? If you guessed zero, you win!

Android Emulator TeamCity Plugin

0
Comment actions Permalink

Ya, mobile development support is a lack in TC. Thanks for that feedback.

Concerning plugin - it's not ours, so you may want to contact the owner by yourself to figure out how it works.

0
Comment actions Permalink

Given that the mobile revolution started for real over 5 years ago it's a lack that's very difficult to understand.

Yeah I am not blaming you for that guy's lack of doc. I think TeamCity has great potential (wish the name were changed, it sounds like the name of a terrible Jefferson Starship song). But it takes so much work to make simple things go. Ugh. Ironically, our Play/Akka/Angular project was the easiest to setup, but that's because the testing tools in Angular are now outstanding (and Grunt makes them easy to run from the command line).

0
Comment actions Permalink

Teamcity tries to cover everything with focus to teams that use continous integration extensively.

Mobile development is wide, but we are assuming there are not too many mobile projects that have tests and that more than one developer participate in.

We'll be glad to be wrong in our assumption, but so far we are not sure that efforts put into mobile development (and that should be significant efforts) would reasonably pay back.

0
Comment actions Permalink

Interesting.. you may be right, but Apple spent a lot of effort on tests and continuous integration. What they have is pretty impressive actually, just does not work for me yet. Probably will eventually, but that still leaves android.

Development is always saying it wants to do only what is needed by the masses. How did that work out on OSGi? lol.. sadly the shoemakers all made shoes only other shoemakers would want.

At some point you also just have to ask yourself the question will this product (Team City) ever be sufficiently extensible that these very typical scenarios don't turn into smoking holes. Sounds like your answer to that is 'nope.'

0
Comment actions Permalink

If you mean XCode service, I saw it. It has some features that makes integration with iOS devices easy, but lacks workflow features that makes continous integration powerful and flexible.

Basically, it's a problem of a tool for everybody. But, again, since mobile projects mostly aren't big, they don't really use lots of Teamcity features that makes it really cool.

In addition, we don't know too much about needs of mobile developers. If somebody (or a group of people) starts a plugin that will make the life of mobile developers easier, we will definetely consider contributing some code into it. The plugin you mentioned earlier is an interesting one thank you. I will look into it. Probably, it can be some kind of start.

0

Please sign in to leave a comment.