Getting started with Testributor

Sign up

  1. Visit

  2. Signup either with email and password or using your Github account.

Add a project

You can follow the wizard on this page to add a project. You will be asked to authorize Testributor to access your repositories on Github or Bitbucket (unless have already done so).

You will also need to create the testributor.yml file. This is the file which describes the “jobs” that compose your test suite. You can read more on how to create this file here.

The last step is optional. You can select technologies (database etc) and the language of your project. This will produce a docker-compose.yml file, which you can use to spawn your first worker. The page will redirect automatically when the worker goes live. You can skip this step and add a worker later if you so desire.

Keep in mind that when a repository is public (on GitHub or Bitbucket), it is also flagged as public on Testributor. That means, any user will be able to visit the Build pages and see the results of your tests. They will not have access to any configuration or credentials. This is a sane default for public projects but if you want to mark your project as private on Testributor anyway, you can do that from the Settings of your newly created project.

Override files and create file

Your test suite will run in an environment consisting of one or more Docker containers. Your project might depend on some packages which might not be available by default. Also you might need to run some commands to prepare the database before your suite can be run.

These actions can be performed through the file which you can find under “Files” menu on the left inside your project’s dashboard.

For your convenience, the documentation for this file and some examples can be found on the same page.

Under “Files” you can also find the “testributor.yml” file you created previously. You can also create any file that might not live in your git repository or override any file which needs to change in order to be able to run your suite.

An example would be the “database.yml” file in Ruby on Rails projects. It is common practice to keep this file outside source control in order to let developers set their own credentials on their workstation.

Since you might be overriding database connection details or other service credentials, any information you need about the technologies you selected on the project import wizard, can be seen on the right at this page.

It usually includes host names, ports and credentials for the various services.

NOTE: If you are not sure what files to override or what to add in build commands, don’t worry. The best way to get it right is through trial and error.

Don’t spend too much time thinking about this and move on to setting up a worker. Your worker will complain if something is not there. That will help you find what’s missing.

Setting up a worker

A worker is a group of Docker containers that compose the environment in which your test suite will be run. Every technology you select in project “Settings” page is connected with a Docker image living on Dockerhub.

The “Language” image you select under “Settings -> Worker setup” is an image which includes our application that talks to our service and fetches jobs for execution.

You can run multiple workers on the same machine if your CPU, RAM and the rest of the resources allow that.

To create a worker you should download the docker-compose.yml from the “Settings -> Worker setup” page. Then, from the directory where this file resides, you should run a command like

  docker-compose -p worker_1 up -d

To see other options for docker-compose check the official documentation.

Add a build

After you succesfully start the worker you will want to add a new Build to test the previous configuration. Go to the dashboard of your project (top link on the sidebar when inside a project). Then select a tracked branch or add a branch using the button on the top right corner. The click on the branch name and use the button on the top right corder of the page to add a new build.

Watch the worker’s logs for errors:

  docker-compose -p worker_1 logs

(We assume that you named your worker “worker_1”. If not, use the same name you used when you started the worker)