Customizing Enterprise Worker Configuration

Credentials for Connecting to the Platform #

With Ubuntu 16.04 as host operating system #

The configuration for connecting to the Travis CI Enterprise platform can be found in /etc/default/travis-worker. If you need to change the hostname the Worker should connect to, or the RabbitMQ password, you can do so by updating:

export AMQP_URI="amqp://travis:<rabbitmq password>@<your-travis-ci-enterprise-domain>/travis"

With Ubuntu 14.04 as host operating system #

The configuration for connecting to the Travis CI Enterprise Platform, including the RabbitMQ password, can be found in /etc/default/travis-enterprise.

If you need to change the hostname the Worker should connect to, or the RabbitMQ password, you can do so by updating:

export TRAVIS_ENTERPRISE_HOST="<your-travis-ci-enterprise-domain>"
export TRAVIS_ENTERPRISE_SECURITY_TOKEN="super-secret-password"

Setting Timeouts #

The following options can be customized in /etc/default/travis-worker. It is recommended to have all Workers use the same config.

By default, jobs can run for a maximum of 50 minutes. You can increase or decrease this using the following setting:


If no log output has been received for more than 10mins, the job is cancelled as it is assumed the job stalled. You can customize this timeout using the following setting:


Configuring the Number of Concurrent Jobs #

The number of concurrent jobs run by the worker and the number of CPUs allowed for a job to use are configured with the TRAVIS_WORKER_POOL_SIZE and TRAVIS_WORKER_DOCKER_CPUS environment variables, respectively. Each Job requires a minimum of 2 CPUs, and by default, each Worker runs 2 jobs. The product of TRAVIS_WORKER_POOL_SIZE * TRAVIS_WORKER_POOL_SIZE cannot exceed the number of CPUs the worker machine has, otherwise jobs will error and requeue.

To change the number of concurrent jobs allowed for a worker to use, please update the following setting:


To change the number of CPUs a job is allowed to use, please change the following setting:


To completely disable this setting, set the value to 0. Then resources will be used as needed, which means a single job can for example use all CPU cores.


Changing the Worker Hostname #

Each Worker should have a unique hostname, making it easier to determine where jobs ran. By default this is set to the hostname of the host the Worker is running on.


Disable SSL Verification Messages #

The Platform comes set up with a self-signed SSL certificate. This option allows the Worker to talk to the Platform via SSL but ignore the verification warnings.


Enabling S3 Dependency Caching #

If you would like to set up S3 dependency caching for your builds, you can use the following example config:


Configuring Jobs’ Allowed Memory Usage #

The Worker comes configured with the RAM defaulted to 4G. If you want to change it, you can add the following. To completely disable it, set the value to 0.

# OR

Setting Maximum Log Length #

The Worker comes configured with defaultMaxLogLength = 4500000 which is 4.5MB. The setting is measured in bytes, so to get 40MB you need 40000000.


Mounting Volumes across Worker Jobs on Enterprise #

You can use Docker bind mounts when the worker launches the container of a job. This lets you share files or directories across all jobs ran by a worker. Multiple binds can be provided as space separated strings.

For example, the setting below shows how to share the /tmp directory in read/write mode, as well as the /var/log directory in read-only mode (:r is the default):

export TRAVIS_WORKER_DOCKER_BINDS="/tmp:/tmp:rw /var/log"

A full list of options and mount modes is listed in the official Docker documentation.

Worker behind an HTTP(S) Proxy #

If you’re using Travis CI Enterprise behind an HTTP(S) proxy, we’ve got you covered. Since travis-worker 4.6 it is possible to run builds behind a proxy.

How do I find out if I have the correct travis-worker version installed? #

Ubuntu 16.04+ #

Connect to your worker machine via SSH and run:

$ sudo docker images | grep worker
travisci/worker        v4.6.1                      ef7a3419050c        17 hours ago        44.7MB

Ubuntu 14.04 #

Connect to your worker machine via SSH and run:

$ travis-worker -v
travis-worker v=v4.6.1 rev=73392421d0ca807b83d4d459ad3dd484820fd181 d=2018-10-30T16:13:39+0000 go=go1.11.1

Upgrade travis-worker #

If you need to install a newer version of travis-worker, please follow the instructions in our Updating your Travis CI Worker docs.

Configuring an HTTP Proxy #

On the worker machine, please open /etc/default/travis-worker in your editor and add the two lines from the example below. The value for TRAVIS_WORKER_DOCKER_API_VERSION depends on the installed Docker version.


In this example we’ve used Docker-CE 17.12. According to the API mismatch table we need to choose 1.35 for TRAVIS_WORKER_DOCKER_API_VERSION.

Below you can find the full list of available environment variables and how they’re accessible during the build:

Environment variable Available as:

Please note, that all apt-get commands by default respect TRAVIS_WORKER_DOCKER_HTTP_PROXY and TRAVIS_WORKER_DOCKER_HTTPS_PROXY which means that all package installs will go via the HTTP Proxy as well. If you don’t want this to happen, please whitelist your apt package mirror by adding it to TRAVIS_WORKER_DOCKER_NO_PROXY` like this:


How to set LXD worker specifics #

After running the the LXD worker configuration is stored in /var/snap/travis-worker/common/worker.env.

All parameters mentioned on this page with the exception of Docker parameters apply to LXD. Below you can find a list of available parameters:

Parameters Definition:
TRAVIS_WORKER_LXD_CPUS defines how many CPU’s can be used by LXD, the default is 2.
TRAVIS_WORKER_LXD_CPUS_BURST defines if all CPU’s can be used by LXD if not already in use, the default is True.
TRAVIS_WORKER_LXD_DISK LXD disk size limit, the default is 20Gb.
TRAVIS_WORKER_LXD_ARCH_OVERRIDE overrides the architecture defined in the job configuration, not present by default.
TRAVIS_WORKER_LXD_MEMORY defines the memory available for each container, the default is 4Gb.
TRAVIS_WORKER_LXD_NETWORK defines the network bandwidth, the default is 1Gb.

Contact Enterprise Support #

To get in touch with us, please write a message to If possible, please include as much of the following as you can:

  • Description of the problem - what are you observing?
  • Which steps did you try already?
  • A support bundle (see table below on how to obtain it)
  • Log files from all workers (They can be found at /var/log/upstart/travis-worker.log - please include as many as you can retrieve).
  • If a build failed or errored, a text file of the build log
TCI Enterprise version Support bundle
3.x Run kubectl kots admin-console -n [namespace] to access admin console on http://localhost:8800
Support bundle generation instruction is available in ‘troubleshoot’ menu or directly at: http://localhost:8800/app/tci-enterprise-kots/troubleshoot

A command for generating support bundle will appear after selecting:
If you'd prefer, [click here]() to get a command to manually generate a support bundle.
2.x+ You can get it from https://<your-travis-ci-enterprise-domain>:8800/support

Since the announcement in Q3 2020, the most up to date version of Travis CI Enterprise is 3.x line. There are not any new releases for version 2.2 and the support patches has been limited since March 2021 as well. For existing users of Travis CI 2.x we strongly recommend upgrading to the latest Travis CI Enterprise 3.x.

Have you made any customizations to your setup? While we may be able to see some information (such as hostname, IaaS provider, and license expiration), there are many other things we cannot see which could lead to something not working. Therefore, we would like to ask you to also answer the questions below in your support request (if applicable):

  • How many machines are you using / what is your Kubernetes cluster setup?
  • Do you use configuration management tools (Chef, Puppet)?
  • Which other services do interface with Travis CI Enterprise?
  • Which Version Control system (VCS) do you use together with Travis CI Enterprise (e.g., GitHub Enterprise, or BitBucket Cloud)?
  • If you are using GitHub Enterprise, which version of it?

We are looking forward to helping!