To setup your workers visit Settings -> Worker setup

On this page you can see 2 sections.

Build your docker-compose.yml file section

build_your_docker_compose_yml

On the top section you select the base image for your project based on the language you use. If you can’t find a suitable image for your project, try the “Generic” image option.

These images have our “agent” installed. As soon as the base image starts the agent will connect to Testributor and start running jobs (eventually).

Below the base image selection, you can select any number of technologies you want. These technologies are Docker images which will be linked to the base image when you start your Docker containers. Don’t worry if you can’t find the image you want here. These images have no modifications, you can actually use any image you have access to.

This brings us to the next field (Custom yml data). By clicking on “Save” button on the bottom of this form, you can see a preview of the docker-compose.yml file on the right.

It you want to make additions or modifications to this file, but still be able to download the generated file instead of maintaining your own version, you can use the Custom yml data field. Add some valid yml data in this field and click “Save”. Unless you make some syntax error, or you enter something that makes no sense (like a simple word for example), the custom data will be merged to the docker-compose.yml preview on the right.

The preview you see on the right, is actually the generated docker-compose.yml for the first of your worker groups (See next section).

Worker Groups section

worker_groups_section

Here you can create sets of credentials both for our API and for access to the third party service (GitHub/Bitbucket) if any. The reason for this is that you might want to have fine grained control over the permissions and access both on our service and on the repository.

For example, if you have a team of 4 developers and each one wants to run a couple of workers on her workstation, you should better create a different worker group for each developer. This way, if someone leaves the team, you can delete the worker group without forcing everyone to create the workers from scratch. The deleted worker group will also delete the SSH keys from GitHub/Bitbucket (unless this is a Bare repository project in which case there is no third party service involved).