XCODE and a CI that doesn’t suck

Apple makes great hardware and good software. The latest part in the shape of an SDK, saves hundreds of hours when you walk the same exact path they THOUGHT you would walk without their guidance.
The second that you look funny to another way of doing the same exact thing, you run into these situations that your dev peers reply with “it works on my machine”. Now, you are on your own. The more you scout the net armed of will, frustration, coffee and Google the more you dig deep your grave. As for every random attempt that original peeking in the dusk becomes your early death and your dev environment will be soon a Phoenix coming back from the ashes, with a new installation.
There’s also another issue. XCode provides a great CI experience if you stay aligned with the same matching version of the server.app. If your project cannot move on, right away, the folks at Apple don’t see that as a problem. Internally they don’t have this problem so they can’t foresee or hear your pain…
That’s when you start looking for another way of doing the same thing, with less pain, more portability and basically for free. Granted that the server app is just $20 every year, your time in getting that to work the limited way it should be is worth a lot more.

Entering Jenkins.

It’s a super reliable, elaborate system of running your builds and therefore to test your code as you go. Most people call it: Continuous Integration or CI for short. It supports plugins; therefore you can extend the tool basic functionalities to what most people use or you can adventure and build your own plugins.
You can run it off of many platforms and likely you will be running it on a mac mini as it is the most common setup. Unless you decide to run it from an Ubuntu setup. There are already very good tuts out there on how to configure it.
My selection fell on these kind writers that took the time to experiment and document.
  1. Get the basics. It doesn’t really work, however, it teaches what you really need to know. So going thru that article is enlighting to understand what you need to know.
  2. Oh I see now. How do I make this work then?…. This article is really the best I have found, complemented with this one that has all the keys to really make it work.
  3. Once it works, you want to take it to the next level and that’s when you will be looking at this article. That is when the heavens bells will be entering your realm.
I recommend you go thru the articles, however just in case you want to save yourself some additional time, here my gist:
  1. Download the version for your OS from Jenkins.io, don’t just push the red button. Use the combo to select.
  2. After the installation is completed, to give your Jenkins installation access to your private GIThub/Bitbucket repos, follow this article. It’s super short and makes you do exactly what you need.
  3. You will run into several issues during your tests, do not attempt to fix them while logged in your default user, log into the system using the jenkins user created by the installation.
  4. Your simulator will cause several levels of pain, you are not alone. However, there’s a cure to that and it’s not a bad tasting medicine.
At this point you get it, you understand. You feel even pretty good about what you have accomplished thus far. You want to take it to the next level. Code coverage, send results of your tests via email, posting on slack CI results and so on. 
Now, you wanna party with this brand new CI system like there’s no tomorrow. Even exploring all the insights of the configuration system and beyond. To get there, I will dedicate an entire article on my next post. Click follow if you want to be automatically notified or comment below. Both ways achieve the same result.
Some of you instead will want to run it locally as your current default user. To achieve that, there is way less consistent material out there. In short here is what you have to do:
  1. Edit your /Library/LaunchAgents/org.jenkins-ci.plist 
  2. Change groupname and username from jenkins to your username
  3. Acquire permission rights for the log folder using
    sudo chown -R YOURUSER /var/log/jenkins/
  4. Do the same for the home folder for the shared jenkins user, using this
    sudo chown -R YOURUSER:staff /Users/Shared/Jenkins
  5. Stop and restart the daemon with the commands that you have learned thru the articles I linked above
Now you can run Jenkins from your own user and resolve many of the flakiness of the simulator puking back timeout messages and other non-human readable code errors. Occasionally you get the simulator stack and the next build won’t start because the previous build didn’t clean before leaving. A simple
killall simulato || true
resolves the issue.
I quickly jotted down my notes for my own reference in future and to save to many of you hundreds of hours of google search. In my next article I will go deep with a detailed step by step tutorial to help you in getting the job done at a very professional level. For the time being, have a good read of the links above. Thanks to the respective authors, I was able to acquire a ton of knowledge in a very short time and with mildly little swearing. Even my mice was surprised, the bluetooth keyboard didn’t lose connection. All in all a big victory.
Happy CI and soon, new year!

Comments

Popular posts from this blog

Postgres on Synology

The Making of Basculo

Build an independent watch app - Part II