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
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 #
After enabling the feature flags for custom queues, configure the job routing in the management console. This is defined in yaml, in the Advanced Configuration YAML section at the bottom of the management console Settings page, e.g.
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 be an org or a user
slug- a repository, in the form:
† Specify the
group for a job in the
.travis.yml. Do not specify ownership-type selectors (
slug) in the configuration. See the example for more details.
Note: We do not recommend using
osfor 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 Example #
The syntax for the Advanced Configuration YAML field is very important. 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
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 email@example.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 (You can get it from
- 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
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 can’t see which could lead to something not working. Therefore , we’d like to ask you to also answer the questions below in your support request (if applicable):
- How many machines are you using?
- Do you use configuration management tools (Chef, Puppet)?
- Which other services do interface with Travis CI Enterprise?
- Do you use Travis CI Enterprise together with github.com or GitHub Enterprise?
- If you’re using GitHub Enterprise, which version of it?
We’re looking forward to helping!