Configuration Reference

Configuration files

Configuration of the stb-tester nodes in your test farm is done by modifying the following files in the test-pack git repository.

  • .stbt.conf: An “ini” format file that configures your test farm and the run-time environment in which testcases are executed. See .stbt.conf below.
  • config/test-farm/<hostname>.conf (optional): Allows overriding configuration values for a specific stb-tester node in your test farm. See node-specific-config below.
  • config/remote-control/
  • config/setup/setup: An optional script to perform custom configuration of the environment in which your testcases are run. See Customising the test-run environment.


The file .stbt.conf in the root of your test-pack is a configuration file in the “ini” format that specifies the run-time environment in which testcases are executed.

By default this file is a symlink to config/stbt.conf.

stbt_version = 29
default_remote_control = XBox

lang = eng
  • test_pack.stbt_version specifies the version of the stbt Python API that your testcases use. This pins the test execution environment to a specific version of the stbt core Python API.

    This allows you to manage upgrades of the stbt core Python API in a controlled manner, and to test the upgrade (by changing this setting in a branch of the test-pack git repo before committing it to the master branch). See the Release notes for the differences between each version.

    Allowed values:

    • 29
    • 28
    • 27
  • test_pack.default_remote_control specifies which remote control will be selected by default in the web interface, and in the run_tests REST API if you don’t specify remote_control. This is most useful in node-specific config files, when you have different stb-tester nodes connected to different models of set-top boxes.

    For example if you have an infrared configuration file called XBox.lircd.conf, here you would specify default_remote_control = XBox.

    The special value roku_http enables a proprietary HTTP protocol for controlling Roku models that don’t have an infrared receiver. See Testing the Roku Streaming Stick+ with Stb-tester.

  • test_pack.portal_url specifes the URL of the portal this test-pack is associated with. This is used by stbt_rig to know which portal to talk to. You shouldn’t need to modify this value.

    Example: portal_url =

Node-specific configuration files

You can configure individual stb-tester nodes by creating the file config/test-farm/<hostname>.conf (for example config/test-farm/stb-tester-c03fd562ae33.conf). The hostname is labelled on the physical stb-tester node, and it is also shown in the stb-tester portal.

friendly_name = PS4

ip_address =

You can specify any value that is allowed in .stbt.conf above; as well as the following values:

  • node.friendly_name specifies a name for displaying in the portal. This makes it easier to identify each stb-tester node. You can use it to describe the device-under-test that it’s connected to (for example “Roku” or “PS4”) or a physical location (for example “Rack 3 Shelf 2”).

Automatic configuration keys

stb-tester sets some configuration keys at run-time to expose information about the environment in which the tests are being run. You can then retrieve this information during the test-run using the stbt.get_config Python API. These are set automatically and you should not set these values in your configuration file.

  • node.node_id is the id of the node that the test is currently being run on, e.g. stb-tester-00044b80ebeb.
  • node.portal_url is the url of the portal that the test is currently being run on, e.g. This will usually have the same value as test_pack.portal_url - but it is set automatically during a test-run rather than recorded in the configuration file itself.

The following config values mirror the return type from the /api/v2/results/(result_id) REST API. See the documentation there for reference.

  • result.result_id
  • result.job_uid
  • result.result_url
  • result.triage_url
  • result.start_time
  • result.test_case
  • result.test_pack_branch
  • result.test_pack_sha
  • result.username
  • result.tags.<tagname> - Use get_config("result.tags", "tagname") to retrieve the value of a tag passed to the /api/v2/run_tests REST API endpoint when starting the test job. This provides a mechanism for passing parameters to tests.

The following config values mirror the return type from the /api/v2/jobs/(job_uid) REST API. See the documentation there for reference:

  • job.job_uid
  • job.job_url
  • job.start_time

Reading configuration values in your test scripts

You can store your own custom configuration values in the .stbt.conf and config/test-farm/<hostname>.conf files. Please use a different section name (not [test_pack]) to avoid clashes with configuration keys that we might add in the future. For example:

stb_ip =

Then you can access this configuration value in your test scripts by using stbt.get_config. For example, if your device-under-test allows retrieving logs over HTTP you might use something like this:

stb_ip = stbt.get_config("my_company_name", "stb_ip")
print requests.get("http://%s/logs" % stb_ip).text

Customising the test-run environment

You may wish to use different Python libraries or other packages in your test scripts. For example you might want the socat program installed to collect more information from the system-under-test.

Stb-tester allows you to run arbitrary commands to set-up your test environment, including installing Ubuntu packages with apt-get install and Python packages with pip. Each test job will then run in a pristine copy of the environment you design.


Save the following file into your test-pack as config/setup/setup:

#!/bin/bash -ex

# Install Ubuntu packages
export DEBIAN_FRONTEND=noninteractive
sudo apt-get update
sudo apt-get install -y \
    python-requests \

# Install Python packages
sudo pip install pylint==1.3.1

Set the executable bit:

chmod a+x config/setup/setup

Commit and push your change:

git add config/setup/setup
git commit
git push

Now the first time you run a test, the setup script will be run to create the test environment and you will be able to import requests in your Python test-scripts.


  • Each test-environment will be built just before it is needed and cached so you don’t need to wait for it to be built for every test run. Cached environments are forgotten when the Stb-tester node is powered off, so it will be re-created as needed after a reboot.

  • If you change the setup script, then a new environment will be built the next time you run a test.

  • When the setup script is run it will have no access to the rest of the test-pack sources. It will be installed into /var/lib/stbt/test-pack/config/setup/setup and executed from the working directory /var/lib/stbt/test-pack.

  • The setup script will be run in a vanilla Ubuntu 14.04 environment with stb-tester installed. The stb-tester version is determined by test_pack.stbt_version in .stbt.conf.

  • The setup script must return a non-zero exit status if it fails to set up the environment correctly (for example if it is a shell script, use set -e).

  • images/v27.3-job-logs.png

    If the setup script fails no tests will be run. To see the output from the setup script click the “Logs” link.

  • You can test your setup script by running stbt-docker from a checkout of the test-pack on your PC.

Customising the manual remote control image

The following instructions are also available as a video here.

To add an infrared remote-control configuration see Remote control configuration. The following instructions are to configure a custom graphic for your remote control in the Manual control tab of the Stb-tester portal:


The available remote controls (in the drop-down list) come from the config/remote-control/*.lircd.conf files in your test-pack git repository.

When you select a remote control from the drop-down list, the Stb-tester portal displays an image of the remote control with buttons you can click to send the corresponding infrared signal to the system-under-test.

You can customise this image by creating an SVG file with the same prefix as the *.lircd.conf file. For example, if there’s an infrared configuration file called rcu123.lircd.conf, the corresponding SVG file is rcu123.svg.

You only need to do this if Stb-tester’s built-in SVG doesn’t have all the buttons you need.

  1. Create a new SVG with a vector-graphics program (we recommend Inkscape).

    • Instead of starting from scratch, you can copy Stb-tester’s built-in SVG.
  2. Each SVG element that will be a clickable button must have a class attribute set to the value key, and a key attribute set to the name of the key as specified in the lircd.conf file.

    For example:

    • class=key

    To do this in Inkscape: select Edit > XML Editor, then click on the element you want to edit, and add the class and key attributes.

  3. Commit the SVG image to the test-pack git repository, and use git push to push your commit to the upstream repository on GitHub.

Instead of drawing the remote control from scratch with vector graphics, a useful technique is to import a jpeg or png image of your remote control into the vector-graphics program. When it asks you whether to embed the image or link to it, choose “embed”. Then draw rectangles or circles on top of each button and set the attributes of these shapes as described above. These shapes must be in the foreground layer, and they must have a solid fill. However you can set the alpha channel of the fill colour to 1% which makes it effectively invisible (so that you can see the original button in the bitmap image underneath).