Enterprise Customer Worker Queues

Custom queues give your team more granular control over routing jobs to specific workers. This is especially helpful in conjunction with customized worker configuration and/or modified build environments.

There are two feature flags required for custom queues. After setting these flags, you can define the configuration for your queues in the Management Console settings and allocate workers to the new queues

Enable Queues on the Platform #

To allow your Travis CI Enterprise platform instance to route jobs to customized queues, set the template_selection and multi_os feature flags. To do this, ssh into your platform server, then run travis console. Run the following command to enable the required feature flags:

Travis::Features.enable_for_all(:template_selection); Travis::Features.enable_for_all(:multi_os); exit

The new settings will take effect immediately, but job routing will remain the same until new queues are defined.

Define Custom Queues in the Management Console #

Configure the job routing in the management console after enabling the feature flags for custom queues. This is defined in YAML, in the Advanced Configuration YAML section at the bottom of the management console Settings page, e.g., https://<your-travis-ci-enterprise-domain>:8800/settings.

There are a number of options/selectors used to define routing to a custom queue. Repos that match all of the selectors for a custom queue will be built on that custom queue. We recommend using the following selectors:

• language - defines the build environment based on the chosen language of the project†
• group - mostly semantic, for defining ‘groups’ of environments†
• owner - either an org or a user
• slug - a repository, in the form: org/repo or user/repo

† Specify the language and group for a job in the .travis.yml. Do not specify ownership-type selectors (owner, slug) in the configuration. See the example for more details.

Note: We do not recommend using dist and os for these selectors. These two have some of their own routing processes built-in and may not entirely behave as intended.

Define selectors in “Advanced Configuration YAML” in the following format:

production:
  queues:
  - queue: name
    selector: value
  - queue: another.queue
    selector: different_value
    selector: something_else

See the example for details on syntax. Click ‘Save’ on the Management Console Settings when you are ready. Travis CI Enterprise will restart with your new queue settings.

Advanced Configuration YAML #

The syntax for the Advanced Configuration YAML field is very important. An incorrect syntax will result in builds being routed to defaults, usually a builds.linux queue, depending on if there are any modifications to your installation. Here’s an example of a custom queue definition:

production:
  queues:
  - queue: builds.ruby
    owner: travis-ci
    language: ruby
    group: enterprise
  - queue: builds.python
    owner: acnagy
    language: python
  - queue: dockercluster
    services:
    - docker
  - queue: legacy
    group: legacy
  - queue: docs
    slug: 'travis-ci/docs-travis-ci-com'

For this example, to build an enterprise Ruby project owned by the travis-ci organization, a .travis.yml would need to look as follows:

group: enterprise
language: ruby
# rest of the yaml, per standard spec

Building the travis-ci/docs-travis-ci.com repo, however, does not require any special configuration.

Define Custom Queues Settings on The Workers #

To allocate a worker to a particular queue, define the QUEUE_NAME variable in the worker config. This is located at etc/default/travis-worker. Update the environment variable to match the queue name specified in your custom queue configuration YAML. Then restart the worker with:

sudo service travis-worker restart

The new queue settings will take effect upon restart.

Contact Enterprise Support #

To get in touch with us, please write a message to enterprise@travis-ci.com. 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

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.com, GitHub Enterprise, or BitBucket Cloud)?
• If you are using GitHub Enterprise, which version of it?

We are looking forward to helping!