What is Travis CI?

Travis CI is a hosted continuous integration platform that is free for all open source projects hosted on Github.

With a file called .travis.yml, you can trigger automated builds with every change to your repo.

How to use Travis CI?

1. Sign in to Travis CI with your GitHub account.

2. Go to your profile page and choose a repository to run Travis CI builds.

3. Put a file called .travis.yml, which tells Travis CI what to do, in the root of your repository.

4. Edit the empty NewUser.txt file by adding your name to the empty file. Add the file to git, commit and push, to trigger a Travis CI build.

$ git add -A
$ git commit -m 'Testing Travis CI'
$ git push

1. Wait for Travis CI to run a build on your repository, check the build status and notice that the build fails. (Travis CI sends you an email when this happens)

.travis.yml

your .travis.yml file may tell Travis CI:

• What programming language your project uses
• What commands or scripts you want to be executed before each build (for example, to install or clone your project’s dependencies)
• What command is used to run your test suite
• Emails, Campfire and IRC rooms to notify about build failures

You can use lint.travis-ci.org to verify this file.

Note that for historical reasons .travis.yml needs to be present on all active branches of your project.

Specifying Runtime Versions

One of the key features of Travis CI is the ease of running your test suite against multiple runtimes and versions. Specify what languages and runtimes to run your test suite against in the .travis.yml file.

A list of languages and runtimes Travis CI supports.

language: node_js
node_js:
  - "4.1"

The above .travis.yml tells Travis CI that this project is written in Node v4.1 .

The Lifecycle

A build on Travis CI is made up of two steps:

• install: install any dependencies required
• script: run the build script

You can run custom commands before the installation step (before_install), and before (before_script) or after (after_script) the script step.

You can perform additional steps when your build succeeds or fails using the after_success (such as building documentation, or deploying to a custom server) or after_failure (such as uploading log files) options. In both after_failure and after_success, you can access the build result using the $TRAVIS_TEST_RESULT environment variable.

The complete build lifecycle is:

1. before_install
2. install
3. before_script
4. script
5. after_success or after_failure
6. after_script
7. OPTIONAL before_deploy
8. OPTIONAL deploy
9. OPTIONAL after_deploy

Customizing the Installation Step

Travis CI uses the default dependency installation commands depend on the project language to install the dependencies. For Node projects, the default dependency installation commands is npm install.

install:
  - npm install

You can specify your own script to run to install whatever dependencies your project requires in .travis.yml.

install: ./install-dependencies.sh

When one of the steps fails, the build stops immediately and is marked as errored.

You can skip the installation step entirely by adding the following to your .travis.yml.

install: true

Customizing the Build Step

The default build command depends on the project language. You can overwrite the default build step in .travis.yml:

script:
  - bundle exec rake build
  - bundle exec rake builddoc

When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well, and accumulates the build result.

If your first step is to run unit tests, followed by integration tests, you may still want to see if the integration tests succeed when the unit tests fail.

You can change this behavior.

script: bundle exec rake build && bundle exec rake builddoc

This example (note the &&) fails immediately when bundle exec rake build fails.

If any of the commands in the first four stages of the build lifecycle return a non-zero exit code, the build is broken:

• If before_install, install or before_script return a non-zero exit code, the build is errored and stops immediately.
• If script returns a non-zero exit code, the build is failed, but continues to run before being marked as failed.

The after_success, after_failure, after_script and subsequent stages do not affect the the build result.

Build Timeouts

Because it is very common for test suites or build scripts to hang, Travis CI has specific time limits for each job. If a script or test suite takes longer than 50 minutes (or 120 minutes on travis-ci.com), or if there is not log output for 10 minutes, it is terminated, and a message is written to the build log.

There is no timeout for a build; a build will run as long as all the jobs do as long as each job does not timeout.

Building Specific Branches

Travis CI uses the .travis.yml file from the branch specified by the git commit that triggers the build.

You can tell Travis to build multiple branches using blacklists or whitelists. Specify which branches to build using a whitelist, or blacklist branches that you do not want to be built:

# blacklist
branches:
  except:
    - legacy
    - experimental

# whitelist
branches:
  only:
    - master
    - stable

If you specify both, only takes precedence over except. By default, gh-pages branch is not built unless you add it to the whitelist.

You can use regular expressions to whitelist or blacklist branches:

branches:
  only:
    - master
    - /^deploy-.*$/

If you don’t want to run a build for a particular commit, because all you are changing is the README for example, add [ci skip] to the git commit message. Commits that have [ci skip] anywhere in the commit messages are ignored by Travis CI.

Deploying your Code

An optional phase in the build lifecycle is deployment.

When deploying files to a provider, prevent Travis CI from resetting your working directory and deleting all changes made during the build ( git stash --all) by adding skip_cleanup to your .travis.yml:

deploy:
  skip_cleanup: true

You can run steps before a deploy by using the before_deploy phase. A non-zero exit code in this command will mark the build as errored.

If there are any steps you’d like to run after the deployment, you can use the after_deploy phase.

Building Node Project

Provided Node.js Versions

• 4.1.x (support provided on demand)
• 4.0.x (support provided on demand)
• 0.12.x (support provided on demand)
• 0.11.x
• 0.10.x (recent stable release)
• 0.8.x
• 0.6.x
• iojs (recent stable release of io.js)

Travis CI uses nvm to specify Node versions. Newer releases not shown above may be used if nvm recognizes them.

language: node_js
node_js:
  - "4.1"
  - "4.0"
  - "0.12"
  - "0.11"
  - "0.10"
  - "0.8"
  - "0.6"
  - "iojs"

This will make Travis CI run your tests against the latest version 0.6.x, 0.8.x, 0.10.x, 0.11.x, 0.12.x, 4.0.x, and 4.1.x branch releases, as well as the latest io.js stable release.

Specifying node or stable will run using the latest stable Node.js release and specifying iojs will run using the latest stable io.js release.

Specifying only a major and minor version (e.g., “0.12”) will run using the latest published patch release for that version. If a specific version is not needed, It is encouraged to specify node and/or iojs to run using the latest stable releases.

Dependency Management

By default, Travis CI will run

$ npm install

to install your dependencies.

Default Test Script

For projects using npm, Travis CI will execute

$ npm test

to run your test suite.

Links

• Building a Node.js project, by Travis CI
• Customizing the Build, by Travis CI
• CI-By-Example, by bevacqua
• Travis-CI: What, Why, How, by Sayanee Basu