Travis CI Tutorial: Getting Started
In this Travis CI tutorial, learn how to set up the popular continuous integration service, and integrate with GitHub so your tests are run automatically. By Ellen Shapiro.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
Pushing to GitHub
Go back to the tab with your newly created GitHub repo. Copy the commands from the “…or push an existing repository from the command line” section:
Copy the text from that section either manually or by clicking the clipboard icon on the right, then paste it into Terminal and press enter. This adds your new GitHub repo as a remote and pushes everything up to it.
Since Travis is now watching this repo, it will notice this push and put a build in the line of all the other open source builds waiting to be run.
Whenever your tests run, you’ll get an email that contains something like this:
Ruh roh! What happened? Click on the big Build #1 Failed to be taken to the results of the failed build:
That warning at the bottom contains one specific line that explains why the build failed:
Could not find .travis.yml, using standard configuration.
What does that mean? Well, .travis.yml file uses YAML to tell Travis how to set up a build. Since Travis works with many different languages, it doesn’t know how to build your specific project without some information about what kind of project it is.
To get a quick look at some of Travis’ best features requiring very little configuration, check out a new branch from the command line by typing the following into Terminal:
git checkout -b travis-setup
Terminal will confirm that you created and checked out a new branch:
Switched to a new branch 'travis-setup'
Next, open your plain-text editor of choice. TextWrangler is particularly helpful here because it highlights the syntax of YAML files automatically, but any plain-text editor will work.
Create a new document and save it in the root of your repo as .travis.yml.
Add the following five lines to your new .travis.yml file:
language: objective-c #1
osx_image: xcode6.4 #2
xcode_project: MovingHelper.xcodeproj #3
xcode_scheme: MovingHelper #4
xcode_sdk: iphonesimulator8.4 #5
Note that YAML will disregard anything prefixed with a # as a comment. Here’s what you’re telling Travis to do with each line:
- Build a project using … Objective-C!? Don’t panic! Even though your project is in Swift, Travis only uses the
objective-c
value to know to build with Xcode command line tools. Since Xcode knows how to tell what’s in Swift and what’s in Objective-C, your Swift project will be just fine. :] - Use the Xcode 6.4 tools to create the build, since you’re using Swift 1.2. This presently requires specifying which VM image you want to use – in this case
xcode6.4
. - Use the specified Xcode project file. Note that if you have a project you want to build using an .xcworkspace (for example, a project using CocoaPods), you can replace the xcode_project parameter with
xcode_workspace
and use your .xcworkspace file as the value instead of your .xcodeproj. - Use the specified scheme to decide what tests to run. Since your default scheme is called MovingHelper, Travis should use that scheme.
- Run the tests on an iPhone simulator, because doing so does not require setting up code signing (which is not covered in this tutorial).
Make sure your .travis.yml file is saved, then add and commit it to Git:
git add .travis.yml
git commit -m "Added .travis.yml file"
Next, push your branch up to your remote:
git push -u origin travis-setup
Reload the webpage for your MovingHelper GitHub repo. You should see something like this, indicating that the branch has made it up to GitHub:
Click the green Compare & pull request button.
Change the title of the pull request to Travis Setup:
Click the green Create pull request button, and Travis will automatically start working. As soon as your build completes, you’ll see something like this on your GitHub page:
Argh! You’ve added the .travis.yml file like you were supposed to, so why isn’t it working?
Click one of the Details links to see the results of this build. A new error leads you directly to the problem:
D’oh! Travis knows the name of the scheme, but because it was automatically created and isn’t shared in your GitHub repository, Travis can’t see it. Fix that by going back to Xcode, and from the scheme drop-down, selecting Edit Scheme…
When the scheme editor comes up, check the Shared checkbox at the bottom of the panel:
Click the Close button, then add and commit all shared data (which will include the new shared scheme):
git add MovingHelper.xcodeproj/xcshareddata
git commit -m "Added shared scheme"
Push up to GitHub again:
git push -u origin travis-setup
Since you already have an open pull request, Travis will immediately know that you added changes and start building again:
Once the build completes, you should see what you’ve been waiting for: green!
All is well indeed. Click on Show all checks and the dialog will expand, showing you the builds which passed:
Click on either Details link, and you’ll be taken to Travis’ output. You can scroll through and see the details of how your project was built and how your tests ran, but the bottom line – and the good news – is all the way at the end:
Each item with a green checkmark next to it is a passing test – and as you can see with the happy green text at the end, all of the tests are passing! Woohoo!
Go back to your GitHub page and click the green Merge pull request button, then click Confirm merge to officially merge your changes.