Travailing with Travis
April 21, 2015 § Leave a comment
Recently one of my projects at work has been implementing and customizing Travis to fit my company’s needs.
Let me first vent my feelings by saying: Ew.
I’m not a huge fan of Travis, but I’ve spent enough time with it that I can say that I’m fairly comfortable with the basic set up.
- Travis CI for iOS – Hands down the one link that helped me a ridiculous amount in getting the initial set up.
I’ve since been in the thick of implementing a travis job that runs in project test suites and deploys to hockey app as well as notifies hipChat of the status of the build for both Swift and Objective-C. There are a few interesting additions I would add to the above link if I had to recreate a similar tutorial from the ground up.
If you’re charged with getting a continuous integration environment going, as part of the setup in the .travis file before the before_script section, be sure include a specification of the osx_image that you will need to use. This will have to be xcode 6.1 and higher. So for instance, in my setup for a swift project, I added this line:
It is interesting to note here that one of the concerns I have with Travis is how quickly they tend to update the availability of their osx_images. For instance, Xcode 6.3 beta was released back in February of this year, along with Swift 1.2, but the image is not available for Travis to build with to the date of the writing of this post. This of course means that we cannot upgrade our projects to Swift 1.2 yet, without switching off of Travis completely. Similarly, the actual version of Xcode 6.3 was released earlier this month, and the image still has not been released, although there are promises to this affect floating around various github issues. Bottom line: we’ll see.
Keep all your scripts as separate as possible. I know it seems rather weird to have about 15 million scripts that the .travis.yml is running, but trust me, the more scalability you have, the happier you will be in the long run. For instance, I went through the setup in the previously linked blog post, and while it was all well and good, as soon as I got one project running, I had to turn around and run the same kind of set up only for an obj-c project that was running multiple targets for multiple products. Double the fun! What I ended up doing, rather than having lots of forks in my code based on product and target type was to have separate scripts per target that were called from the .travis.yml.
For instance, in my .travis, I have a script that runs after the product is built that deploys an artifact to hockey app and notifies hipChat with a message sending along the the appropriate target name that was deployed, along with its install link, version number, and build notes. I also have another script for the same project that does this same project for a different product and target. So I could have had a single script that does this for both products, but it makes a lot more sense to just know which script to go to if there is debugging that needs to happen down the road, without having to fight through a lot of if-else statements. .yml is annoying enough, imo.
Comment all your secure keys.
But seriously, just do something like this:
#hipChat authentication key
– secure: generatedSecureKeyRightUpInHere
Take it from someone that did it the hard way: just make sure you know which “-secure” line is which, because if any of these keys change and you don’t know which is which, you’ll end up either just adding to the key list that travis keeps track of, a lot of garbage values that you don’t even know what they are, -or- you get to re do *all* of them just for the benefit of getting ‘er done. And that’s enough to make a saint say bad words.
Be Patient! The ultimate rule to programming that no one told me about in all those intro classes. 🙂