A common way to customize the build process is to use environment variables, which can be accessed from any stage in your build process.
When you need to define environment variables you can do so in:
- .travis.yml, which are tied to a particular commit.
- repository settings, if they are needed for the build to run and don’t contain sensitive data.
- .travis.yml and encrypted, for sensitive data such as authentication tokens.
If you define a variable with the same name in
.travis.ymland in the Repository Settings, the one in
.travis.ymltakes precedence. If you define a variable as both encrypted and unencrypted, the one defined later in the file takes precedence.
There is also a complete list of default environment variables which are present in all Travis CI environments.
Defining Variables in .travis.yml
Variables defined in
.travis.yml are tied to a certain commit. Changing them requires a new commit, restarting an old build uses the old values. They are also available automatically on forks of the repository. Define variables in
- are needed for the build to run and that don’t contain sensitive data. For instance, a test suite for a Ruby application might require
$RACK_ENVto be set to
- differ per branch.
- differ per job.
To define an environment variable in your
.travis.yml, add the
env line, for example:
env: - DB=postgres - SH=bash
Note that environment variable values may need quoting. For example, if they have asterisks (
*) in them
Defining Multiple Variables per Item
When you specify multiple variables per item in the
env array (matrix variables), one build is triggered per item.
rvm: - 1.9.3 - rbx env: - FOO=foo BAR=bar - FOO=bar BAR=foo
this configuration triggers 4 individual builds:
- Ruby 1.9.3 with
- Ruby 1.9.3 with
- Rubinius latest version (rbx) with
- Rubinius latest version (rbx) with
Sometimes you may want to use environment variables that are global to the matrix, i.e. they’re inserted into each matrix row. That may include keys, tokens, URIs or other data that is needed for every build. In such cases, instead of manually adding such keys to each
env line in matrix, you can use
matrix keys to differentiate between those two cases. For example:
env: global: - CAMPFIRE_TOKEN=abc123 - TIMEOUT=1000 matrix: - USE_NETWORK=true - USE_NETWORK=false
triggers builds with the following
USE_NETWORK=true CAMPFIRE_TOKEN=abc123 TIMEOUT=1000 USE_NETWORK=false CAMPFIRE_TOKEN=abc123 TIMEOUT=1000
Defining Variables in Repository Settings
Variables defined in repository settings are the same for all builds. When you restart an old build, it uses the latest values. These variables are not automatically available to forks. Define variables in the Repository Settings that:
- differ per repository.
- contain sensitive data, such as third-party credentials.
To define variables in Repository Settings, make sure you’re logged in, navigate to the repository in question, choose “Settings” from the cog menu, and click on “Add new variable” in the “Environment Variables” section.
These values are used directly in your build, so make sure to escape special characters (for bash) accordingly.
By default, the value of these new environment variables is hidden from the
export line in the logs. This corresponds to the behavior of encrypted variables in your
Similarly, we do not provide these values to untrusted builds, triggered by pull requests from another repository.
As an alternative to the web interface, you can also use the CLI’s
Variables can be encrypted so that their content is not shown in the corresponding
export line in the build. This is used to provide sensitive data, like API credentials, to the Travis CI build. Encrypted variables are not added to untrusted builds such as pull requests coming from another repository.
.travis.yml file containing encrypted variables looks like this:
env: global: - secure: <long encrypted string here> - TIMEOUT=1000 matrix: - USE_NETWORK=true - USE_NETWORK=false - secure: <you can also put encrypted vars inside matrix>
Encrypted environment variables are not available to pull requests from forks due to the security risk of exposing such information to unknown code.
Encrypting Variables Using a Public Key
Encrypt environment variables using the public key attached to your repository using the travis gem:
gem install travis cd my_project travis encrypt MY_SECRET_ENV=super_secret
To automatically add the encrypted environment variable to your
travis encrypt MY_SECRET_ENV=super_secret --add env.matrix
Encryption and decryption keys are tied to the repository. If you fork a project and add it to Travis CI, it will have different keys than the original.
The encryption scheme is explained in more detail in Encryption keys.
To make using encrypted environment variables easier, the following environment variables are available:
TRAVIS_SECURE_ENV_VARS“true” or “false” depending on the availability of environment variables
TRAVIS_PULL_REQUESTthe pull request number if the current job is a pull request, or “false” if it’s not a pull request.
Default Environment Variables
The following default environment variables are available to all builds.
USER=travis(do not depend on this value)
HOME=/home/travis(do not depend on this value)
JRUBY_OPTS="--server -Dcext.enabled=false -Xcompile.invokedynamic=false"
JAVA_HOMEis set to the appropriate value.
Additionally, Travis CI sets environment variables you can use in your build, e.g. to tag the build, or to run post-build deployments.
TRAVIS_BRANCH:For builds not triggered by a pull request this is the name of the branch currently being built; whereas for builds triggered by a pull request this is the name of the branch targeted by the pull request (in many cases this will be
TRAVIS_BUILD_DIR: The absolute path to the directory where the repository being built has been copied on the worker.
TRAVIS_BUILD_ID: The id of the current build that Travis CI uses internally.
TRAVIS_BUILD_NUMBER: The number of the current build (for example, “4”).
TRAVIS_COMMIT: The commit that the current build is testing.
TRAVIS_COMMIT_RANGE: The range of commits that were included in the push or pull request. (Note that this is empty for builds triggered by the initial commit of a new branch.)
TRAVIS_EVENT_TYPE: Indicates how the build was triggered. One of
TRAVIS_JOB_ID: The id of the current job that Travis CI uses internally.
TRAVIS_JOB_NUMBER: The number of the current job (for example, “4.1”).
TRAVIS_OS_NAME: On multi-OS builds, this value indicates the platform the job is running on. Values are
osxcurrently, to be extended in the future.
TRAVIS_PULL_REQUEST: The pull request number if the current job is a pull request, “false” if it’s not a pull request.
TRAVIS_REPO_SLUG: The slug (in form:
owner_name/repo_name) of the repository currently being built. (for example, “travis-ci/travis-build”).
TRAVIS_SECURE_ENV_VARS: Whether or not encrypted environment vars are being used. This value is either “true” or “false”.
TRAVIS_TEST_RESULT: is set to 0 if the build is successful and 1 if the build is broken.
TRAVIS_TAG: If the current build for a tag, this includes the tag’s name.
Language-specific builds expose additional environment variables representing the current version being used to run the build. Whether or not they’re set depends on the language you’re using.
Other software specific environment variables are set when the software or service is installed or started, and contain the version number:
The following environment variables are available for Objective-C builds.