Share and import yaml snippets to your build configuration

At Travis CI, the main source of configuration for your builds has always been the .travis.yml file stored in your repository, and it can be customized by including configuration when triggering builds with the API.

Today we are happy to announce the new beta feature Build Configuration Imports that allows you to import shared YAML build config parts to your .travis.yml file or config included in API build requests.

Import shared build configurations at Travis CI

Build Config Imports let you save time by defining reusable configuration snippets, so that you can fetch commonly used recipes with a single import line, and standarize your build and deploy configuration across repositories.

Opt in

In order to use Build Configuration Imports, please activate the feature Build Config Validation. You can do so by enabling the “Build config validation” repository setting, or adding version: ~> 1.0 to your .travis.yml file.

Build Config Validation repo setting

Find out more about Build Config Validation in the announcement blog post, and in our documentation.

Build Config Imports in a nutshell

Build Config Imports allow you to create modular build configuration systems that can be shared across many repositories, and not only spare the work of manually duplicating build configuration across those repositories, but also standardize how code is built and deployed in your organization.

Here are the highlights:

  • Any build config can import other configs, by using the new imports key. Imported configs can also import other configs, which makes this feature very composable.

  • Each import can carry a condition, in order for them to be imported under certain circumstances only.

  • Encrypted secrets, such as secure environment variables, can be shared across repositories owned by the same organization or user account (see below for restrictions).

  • Config imports can be versioned (using any Git reference), or just follow whatever version is on the source repository’s default branch.

For example, this build config file imports a number of modular config imports for Node.js versions that build up a matrix of 159 jobs, which is shared across many different repositories.

Another great example are these config files that are shared and imported by various Rust repositories for shipping Docker images and websites to AWS.

Config format

The config format for importing configs looks like this:

# use this to activate build configuration validation,
# or enable the respective repository setting
version: ~> 1.0

# importing a single source from a different repository
import: travis-ci/build-configs:rubies.yml

# importing a single source from the same repository
import: rubies.yml

# specifying a version
import: rubies.yml@v1

# importing multiple configs
  - travis-ci/build-configs:rubies.yml
  - other.yml

# importing multiple configs, specifying a merge mode (see below)
  - source: one.yml
    mode: deep_merge_append # (default)
  - source: two.yml
    mode: deep_merge_prepend

For a more complete walk-through on the config format, please see our documentation on Build configurations Imports.

Merge modes

In order to control how each one of the imported configs is merged (included) into the importing one you can specify a merge mode, using the merge key. If you do not specify a merge mode then the default will be the new mode deep_merge_append.

So far, the only two pieces of build config that Travis CI has ever merged were your .travis.yml file and a build config optionally included in API build requests. For that you were able to choose from the merge modes deep_merge, merge, and replace.

However, when you specify the merge mode deep_merge, arrays (YAML sequences) are overwritten, and until now, there was no way to append or prepend to arrays, such as env vars or addons.

We have now added to additional merge modes deep_merge_append and deep_merge_prepend, which will combine arrays by appending or prepending them respectively.

Given that deep_merge_append functions the way most people do expect, we have made this the new default.

Reviewing imported configs

To make it easier for you to get an overview of what configs were imported and how they were merged, we have updated the View config tab on the build view. It now lists all config sources used, as well as the resulting, normalized and merged build configuration that was used to configure your build.

For example, see this config for how Rust imports the shared config travis-configs/static-websites.yml in order to deploy to AWS Cloudfront.


You can import up to 25 other configs in total.

Build configs from private repositories can only be imported to other private repositories within the same organization or user account, and not to any public repositories.

In order to allow importing configs from a private repository this repository has to allow this by enabling the repository setting Allow importing config files from this repository:


We are excited to see how you will use Build Config Imports!

Please share with us your configuration snippets and feedback in the community forum.

Happy Building!