Travis CI Documentation (original) (raw)

Environment Variables

A common way to customize the build process is to define environment variables, which can be accessed from any stage in your build process.

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

Define Public Variables #

Public 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 .travis.yml that:

Define environment variables in your .travis.yml in the env key, quoting special characters such as asterisks (*). One build will be triggered for each line in the env array.

env:
  - DB=postgres
  - SH=bash
  - PACKAGE_VERSION="1.0.*"

If you define a variable with the same name in .travis.yml and in the Repository Settings, the one in .travis.yml takes precedence. If you define a variable in .travis.yml as both encrypted and unencrypted, the one defined later in the file takes precedence.

Variables’ values are passed to the generated build script verbatim. So make sure to escape any Bash special characters accordingly. In particular, if a value contains spaces, you need to put quotes around that value. E.g., a long phrase should be written as "a long phrase".

Define Multiple Variables per Item #

If you need to specify several environment variables for each build, put them all on the same line in the env array:

rvm:
  - 1.9.3
  - rbx-3
env:
  - FOO=foo BAR=bar
  - FOO=bar BAR=foo

this configuration triggers 4 individual builds:

  1. Ruby 1.9.3 with FOO=foo and BAR=bar
  2. Ruby 1.9.3 with FOO=bar and BAR=foo
  3. Rubinius latest version (rbx-3) with FOO=foo and BAR=bar
  4. Rubinius latest version (rbx-3) with FOO=bar and BAR=foo

Global Variables #

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 global and jobs keys to differentiate between those two cases. For example:

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

triggers builds with the following env rows:

USE_NETWORK=true CAMPFIRE_TOKEN=abc123 TIMEOUT=1000
USE_NETWORK=false CAMPFIRE_TOKEN=abc123 TIMEOUT=1000

Define Encrypted variables #

Before adding sensitive data such as API credentials to your .travis.yml you need to encrypt it. Encrypted variables are not available to untrusted builds such as pull requests coming from another repository.

A .travis.yml file containing encrypted variables looks like this:

env:
  global:
    - secure: mcUCykGm4bUZ3CaW6AxrIMFzuAYjA98VIz6YmYTmM0/8sp/B/54JtQS/j0ehCD6B5BwyW6diVcaQA2c7bovI23GyeTT+TgfkuKRkzDcoY51ZsMDdsflJ94zV7TEIS31eCeq42IBYdHZeVZp/L7EXOzFjVmvYhboJiwnsPybpCfpIH369fjYKuVmutccD890nP8Bzg8iegssVldgsqDagkuLy0wObAVH0FKnqiIPtFoMf3mDeVmK2AkF1Xri1edsPl4wDIu1Ko3RCRgfr6NxzuNSh6f4Z6zmJLB4ONkpb3fAa9Lt+VjJjdSjCBT1OGhJdP7NlO5vSnS5TCYvgFqNSXqqJx9BNzZ9/esszP7DJBe1yq1aNwAvJ7DlSzh5rvLyXR4VWHXRIR3hOWDTRwCsJQJctCLpbDAFJupuZDcvqvPNj8dY5MSCu6NroXMMFmxJHIt3Hdzr+hV9RNJkQRR4K5bR+ewbJ/6h9rjX6Ot6kIsjJkmEwx1jllxi4+gSRtNQ/O4NCi3fvHmpG2pCr7Jz0+eNL2d9wm4ZxX1s18ZSAZ5XcVJdx8zL4vjSnwAQoFXzmx0LcpK6knEgw/hsTFovSpe5p3oLcERfSd7GmPm84Qr8U4YFKXpeQlb9k5BK9MaQVqI4LyaM2h4Xx+wc0QlEQlUOfwD4B2XrAYXFIq1PAEic=
  jobs:
    - 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.

If you define a variable with the same name in .travis.yml and in the Repository Settings, the one in .travis.yml takes precedence. If you define a variable in .travis.yml as both encrypted and unencrypted, the one defined later in the file takes precedence.

Encrypting Environment variables #

Encrypt environment variables with the public key attached to your repository using the travis gem:

  1. If you do not have the travis gem installed, run gem install travis (or brew install travis on macOS).
  2. In your repository directory: 
      travis encrypt MY_SECRET_ENV=super_secret --add env.global
  3. Commit the changes to your .travis.yml.

Encryption and decryption keys are tied to the repository. If you fork a project and add it to Travis CI, it will not have access to the encrypted variables.

The encryption scheme is explained in more detail in Encryption keys.

Define Variables in Repository Settings #

Variables defined in repository settings are the same for all builds, and 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:

To define variables in Repository Settings, make sure you’re logged in, navigate to the repository in question, choose “Settings” from the “More options” menu, and click on “Add new variable” in the “Environment Variables” section. Restrict the environment variable to a specific branch by selecting which branch it should be available to.

Screenshot of environment variables in settings

Environment Variables in the Repository Settings

See the note above on how to format variables’ values correctly.

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 .travis.yml. The variables are stored encrypted in our systems, and get decrypted when the build script is generated.

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 env command.

If you define a variable with the same name in .travis.yml and in the Repository Settings, the one in .travis.yml takes precedence.

Build Config Reference #

You can find more information on the build config format for Environment Variables in our Travis CI Build Config Reference.

Default Environment Variables #

The following default environment variables are available to all builds.

Additionally, Travis CI sets environment variables you can use in your build, e.g. to tag the build, or to run post-build deployments.

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.