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.

Leave a rating/review
Save for later
Share
You are currently viewing page 2 of 4 of this article. Click here to view the first page.

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:

github_after_add_screen_highlighted-676x500

Note: Use what’s on your repo, not what’s shown in the screenshot, since you will need to push to the remote that’s tied to your GitHub username, not mine. :]

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.

Note: Builds on the open-source version of Travis may take a while to run – you’re basically in line with anyone else running open-source tests. And unlike at the Post Office, you can’t skip in line by pretending you’re late for your kid’s dance recital. ;]

Whenever your tests run, you’ll get an email that contains something like this:

travis_initial_build_fail_email-700x338

Ruh roh! What happened? Click on the big Build #1 Failed to be taken to the results of the failed build:

travis_initial_fail_details-700x354

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.

Note: You may get a warning about names prefixed with a . being reserved for the system, but use the dot anyway – Travis will be looking for a file named exactly .travis.yml, so the dot is safe to use here.

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:

  1. 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. :]
  2. 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.
  3. 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.
  4. Use the specified scheme to decide what tests to run. Since your default scheme is called MovingHelper, Travis should use that scheme.
  5. 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:

github_branch_pushed

Click the green Compare & pull request button.

Note: If you don’t see Recently Pushed Branches, click the green button next to the branch name. Leave the base branch as master, but change the compare branch to travis-setup, and then click Create pull request.

Change the title of the pull request to Travis Setup:

github_open_pr_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:

github_travis_setup_fail

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:

travis_need_shared_scheme

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…

xcode_edit_scheme

When the scheme editor comes up, check the Shared checkbox at the bottom of the panel:

xcode_share_scheme-700x393

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:

github_travis_waiting_to_hear

Once the build completes, you should see what you’ve been waiting for: green!

github_travis_success

All is well indeed. Click on Show all checks and the dialog will expand, showing you the builds which passed:

github_travis_success_expanded

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:

travis_initial_success

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.