We use cookies to understand how people use Depot.
Integrations

Travis CI

Authentication

For Travis CI, you can use project or user access tokens for authenticating your build with Depot. We recommend using project tokens as they are scoped to the specific project and are owned by the organization.

Project token

You can inject project access tokens into the Travis CI environment for depot CLI authentication. Project tokens are tied to a specific project in your organization and not a user.

User access token

You can also inject user access tokens into the Travis CI environment for depot CLI authentication. User tokens are tied to a specific user and not a project. Therefore, it can be used to build all projects across all organizations that the user has access.

Configuration

To build a Docker image from Travis CI, you must set the DEPOT_TOKEN environment variable in your repository settings. This can be done through the UI for your repository or via the Travis CLI:

travis env set DEPOT_TOKEN your-user-access-token

In addition, you must also install the depot CLI before you run depot build.

sudo: required
env:
  - DEPOT_INSTALL_DIR=/usr/local/bin
 
before_install:
  - curl -L https://depot.dev/install-cli.sh | sudo sh
 
script:
  - depot build .

Examples

Build multi-platform images natively without emulation

This example shows how you can use the --platform flag to build a multi-platform image for Intel and Arm architectures natively without emulation.

sudo: required
env:
  - DEPOT_INSTALL_DIR=/usr/local/bin
 
before_install:
  - curl -L https://depot.dev/install-cli.sh | sudo sh
 
script:
  - depot build --platform linux/amd64,linux/arm64 .

Build and push to Docker Hub

This example installs the depot CLI to be used directly in the pipeline. Then, docker login is invoked with the environment variables for DOCKERHUB_USERNAME and DOCKERHUB_TOKEN for the authentication context of the build to push to the registry.

sudo: required
 
# Needed just for logging the Docker build context into a registry
services:
  - docker
 
env:
  - DEPOT_INSTALL_DIR=/usr/local/bin
 
before_install:
  - curl -L https://depot.dev/install-cli.sh | sudo sh
 
script:
  - docker login --username $DOCKERHUB_USERNAME --password $DOCKERHUB_TOKEN
  - depot build -t <your-registry>:<your-tag> --push .

Build and push to Amazon ECR

This example installs the depot and aws CLIs to be used directly in the pipeline. Then, aws ecr get-login-password is piped into docker login for the authentication context of the build to push to the registry.

sudo: required
 
# Needed just for logging the Docker build context into a registry
services:
  - docker
 
env:
  - DEPOT_INSTALL_DIR=/usr/local/bin
 
before_install:
  - curl -L https://depot.dev/install-cli.sh | sudo sh
  - curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
  - unzip awscliv2.zip
  - ./aws/install
 
script:
  - aws ecr get-login-password --region <your-ecr-region> | docker login --username AWS --password-stdin <your-ecr-registry>
  - depot build -t <your-ecr-registry>:<your-tag> --push .

Build and load the image back for testing

You can use the --load flag to download the built container image into the workflow.

sudo: required
env:
  - DEPOT_INSTALL_DIR=/usr/local/bin
 
before_install:
  - curl -L https://depot.dev/install-cli.sh | sudo sh
 
script:
  - depot build --load .

Build, push, and load the image back in one command

You can simultaneously push the built image to a registry and load it back into the CI job by using the --load and --push flag together.

sudo: required
 
# Needed just for logging the Docker build context into a registry
services:
  - docker
 
env:
  - DEPOT_INSTALL_DIR=/usr/local/bin
 
before_install:
  - curl -L https://depot.dev/install-cli.sh | sudo sh
 
script:
  - docker login --username $DOCKERHUB_USERNAME --password $DOCKERHUB_TOKEN
  - depot build -t <your-registry>:<your-tag> --push --load .