Travis.yml configuration options

• notifications

  notifications TL;DR

  Manage notification preferences. Optional.

  What are notifications?

  By default, Travis sends an email notification whenever a status changes. You can change that within the config file.
  For more information on notifications, see the detailed documentation.

  When are notifications necessary?

  The notifications section is optional. You'd add this section if you want to change the notifications generated by Travis when it completes the builds, tests, and deployments launched from this travis.yml file.

  notifications example

  
          notifications:
            email:
              recipients:
                - one@example.com
                - other@example.com
              on_success: never # default: change
              on_failure: always # default: always
        

• language

  language TL;DR

  Define the language your project is using. Required.

  What is language?

  The main language of your project will determine the environment set up within Travis. For example, if you have a Ruby project, you'd set up Travis to create a Ruby environment. If you want to set up an environment for multiple languages, or for one language in multiple versions, that's possible but a little trickier.

  For more information on language, see the detailed documentation.

  When is language necessary?

  You always define a language in Travis, and it's usually the very first thing you define in the travis.yml file.

  language examples

  
              language: ruby
              

• env

  env TL;DR

  Define environment variables within the travis.yml file.Optional

  .

  What is env?

  A common way to customize the build process is to define environment variables, which can be accessed from any stage in your build process. You can also set up build matricies within this section.

  
  
  For more information on `env`, see the detailed documentation.

  When is env necessary?

  The best way to define an environment variable depends on what type of information it will contain, and when you need to change it:

  • if it does not contain sensitive information, might be different for different branches and should be available to forks – add it to your .travis.yml
  • if it does contain sensitive information, and might be different for different branches – encrypt it and add it to your .travis.yml
  • if it does contain sensitive information, but is the same for all branches – add it to your Repository Settings

  env examples

  
          env:
            global:
              - CAMPFIRE_TOKEN=abc123
              - TIMEOUT=1000
            matrix:
              - USE_NETWORK=true
              - USE_NETWORK=false
        

• branches

  branches TL;DR

  You can specify certain branches to always test or never test. Optional.

  What are branches?

  Travis CI uses the .travis.yml file from the branch containing the git commit that triggers the build. Include branches using a safelist, or exclude them using a blocklist.
  
  For more information on branches, see the detailed documentation.

  When are branches necessary?

  You'd want to use this section in your travis.yml file if you want to be specific. Maybe you have code on other branches that you want to skip over, or maybe you always want to test the deployment branch just so it's being tested more frequently.

  branches examples

  
          # blocklist
          branches:
            except:
            - legacy
            - experimental
  
          # safelist
          branches:
            only:
            - master
            - stable
        

• services

  services TL;DR

  Some external services, like databases, won't start by default. Use services to change that. Optional.

  What are services?

  Travis CI environments do not start services by default, to make more RAM available to build scripts. Start services by adding them to the services: section of your .travis.yml.
  
  Some examples of services are MYSQL, MongoDB, and ElasticSearch.
  
  For more information on services, see the detailed documentation.

  When are services necessary?

  You'd want to use this section in your travis.yml file if have services integrated with your code that require testing.

  services examples

  
          services:
            - riak
            - rabbitmq
            - memcached
        

• addons

  addons TL;DR

  Include 'APT addons' that are dependencies for your project. Optional.

  What are addons?

  APT addons are a specific type of dependency package. They wouldn't be addressed in the other stages, but can be specifically taken care of here.

  For more information on addons, see the detailed documentation.

  When are addons necessary?

  Use addons if you need to use APT addons.

  addons examples

  
          addons:
            apt:
              packages:
              - cmake
              - time
        

• cache

  cache TL;DR

  You can tell Travis CI to ignore parts of your code that will slow down the build. Optional.

  What is cache?

  Travis CI can cache content that does not often change, to speed up your build process. To use the caching feature, in your repository settings, set Build pushes to ON.
  
  Travis CI fetches the cache for every build, including branches and pull requests. If a branch does not have its own cache, Travis CI fetches the master branch cache. There is one cache per branch and language version/ compiler version/ JDK version/ Gemfile location/ etc. Only modifications made to the cached directories from normal pushes are stored. Please note that cache content is available to any build on the repository, including Pull Requests, so make sure you do not put any sensitive information in the cache.
  
  For more information on caching, see the detailed documentation.

  When is cache necessary?

  This decision may depend on the language of your project. The general rule of thumb is to cache parts of your code that will take a long time to load and won't change very often.
  
  You might choose to cache things for the builds run for every small commit, but then include all portions of your code in tests before merging.

  cache examples

  
        cache:
          bundler: true
          directories:
            - node_modules # NPM packages
        

• before_install

  before_install TL;DR

  These are steps you want completed before the environment is installed on Travis' container. Optional.

  What is before_install?

  In this step, you set up dependencies that are prerequisites for the installation.
  
  For more information on language, see the detailed documentation.

  When is before_install necessary?

  One example of when you'd want to use before_install is if you needed some Ubuntu packages hat were not included in the default standard for Travis.

  before_install examples

  
          before_install:
            - sudo apt-get -qq update
            - sudo apt-get install -y libxml2-dev
        

• install

  What is install?

  Install is the step where you can define exactly what will need to be installed to set up the correct testing environment.

  For more information on caching, see the detailed documentation.

  When is install necessary?

  Install is necessary when you have certain environment requirements. If you know your code will be running under certain circumstances in production, you would use the install step to install whatever necessary to emulate that environment in testing.

  install examples

  
        install:
          - sudo apt-get --yes install snapd
          - sudo snap install hugo
        

• before_script

  before_script TL;DR

  This block is used to further set up your environment before you run your script. Optional.

  What is before_script?

  This is where you can specify steps to be run that aren't necessarily associated with the installation, but aren't necessarily a part of the script either. This optional segment gives you more granular control over how and when things happen.

  When is before_script necessary?

  If you need to copy files, start your database, or declare environment variables, do that in the before_script section.

  before_script examples

  
          before_script:
            - bower install
        

• script

  script TL;DR

  Here, Travis runs the test script. By default, Travis runs the default tests for the set language. Optional.

  What is script?

  By default, Travis will just run the associated default tests for the language. In a node app, it would run npm test.
  
  You can change this behavior by adding a script step.

  When is script necessary?

  Use script when you want scripts to be run that aren't necessarily default to the language, but you want Travis to fail if they exit with a non-zero code.

  script examples

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

• before_cache

  before_cache TL;DR

  When using caches, it may be useful to run a command just before uploading the new cache archive. Optional.

  What is before_cache?

  If you are using caches, and have defined this earlier in your travis.yml file, you can use before_cache to run commands before the cache is actually stored. This gives you more granular control over what information is kept in your cache.
  
  It might seem funny to put this step so late in the game, but this is the point in the build when the cache would be created.
  
  Failure in this phase does not mark the job as failed. For more information on before_cache, see the detailed documentation.

  When is before_cache necessary?

  The dependency management utility may write log files into the directory you are caching and you do not want them to affect the cache. Use the before_cache phase to delete the log files.

  before_before_cache examples

  
          before_cache:
            - rm -f $HOME/.cache/pip/log/debug.log
        

• after_success and after_failure

  after_success and after_failure TL;DR

  These scripts are run after the main script, and depend on the outcome. Optional.

  What are after_success and after_failure?

  These scripts will run based on if the main scripts pass or fail. If the scripts within after_success or after_failure fail, the build is unaffected.
  
  For more information on after_success and after_failure, see the detailed documentation.

  When are after_success and after_failure necessary?

  If you’re using a git push to deploy your repo to a server, you want to do it in the after_success portion.

  after_success and after_failure examples

  
          after_success:
            - test $TRAVIS_PULL_REQUEST = false \
              && git push
        

• after_script

  after_script TL;DR

  Script that runs after the rest of the script process is complete.

  What is after_script?

  Just like the other script steps, this will run scripts. The difference is that these scripts will wait to run until the other steps are complete, and if scripts in after_script fail, your build will not be affected.

  When is after_script necessary?

  You would use the after_script block if there was code you wanted to run after every build regardless of success or failure, and you didn't want its failure to affect the build.

  after_script examples

  
          after_script:
            - build_something_important
        

• before_deploy

  before_deploy TL;DR

  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. Optional.

  What is before_deploy?

  The before_deploy can be used to prepare your deployment, if need be. If you want to make sure that this only runs if your build was successful, you can check the $TRAVIS_TEST_RESULT environment variable.

  When is before_deploy necessary?

  Use before_deploy if there is specific steps that need to be completed before it's okay to deploy, but those steps don't belong in the earlier script portions.

  before_deploy examples

  
        before_deploy:
          - test $TRAVIS_TEST_RESULT = 0 \# check that build passed successfully
            && gulp build \
            && cd dist \
            && npm install --prod \
            && cd $TRAVIS_BUILD_DIR \
            && tar -zcvf amber-storm-$TRAVIS_BRANCH.tar.gz dist
        

• deploy

  deploy TL;DR

  Deploy code that passes the tests straight to production. Optional.

  What is deploy?

  deploy is used to deploy your build via travis-supported deployment providers.
  
  For a list of deployment providers that supported by Travis-CI, check out the official documentation.

  When is deploy necessary?

  You'd use this step if you are using one of the supported deployment providers.

  deploy examples

  
          deploy:
            provider: releases
            api_key:
              secure: securekeyhere
            file: myrepo-$TRAVIS_BRANCH.tar.gz
            on:
              condition: $PRODBUILDCOMPLETE = true
              repo: myname/myrepo
              all_branches: true
              tags: true
        

• after_deploy

  after_deploy TL;DR

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

  What is after_deploy?

  The after_deploy block rus after the Travis deploy block has run. Note that in the case of GitHub releases, our code technically hasn’t deployed to the server yet (it’s just been uploaded to the releases page), so we can tell our server to download that release here.

  When is after_deploy necessary?

  If you have code you want to run after the deployment has taken place, and it's outside the parameters of what can be done in the deploy step.

  after_deploy examples

  
          after_deploy:
            - ssh git@website.org "./deploy.sh $TRAVIS_BRANCH"