Appearance

Test Runner Deployment Overview ​

The Test Runner is deployed to test fixtures as a set of containers managed by balenaCloud. This section covers how new versions of the Test Runner software are built and rolled out to fixtures in the field.

How balenaCloud Deployment Works ​

On balenaCloud, a deployment produces a release — a Docker image, or set of images, built from the source in the Opal repository and stored in the balena registry. Every device in the fleet is notified of the new release and downloads and runs it according to the fleet's update strategy. Because the Test Runner is a multicontainer application (backend, browser, pytest-f3ts-api, pytest-f3ts-worker, and runner-frontend), balena uses the docker-compose.yml at the root of the project to determine what to build.

balena ships only the changes between releases using delta updates, so devices don't re-download images that haven't changed.

For full details, see the upstream Balena documentation: Deployment.

Before You Start ​

Before deploying, make sure you have:

  1. Installed the balena CLI — follow the balena CLI installation guide.
  2. Created a fleet on your Balena dashboard for your test fixture — see Create a fleet.

Once the CLI is installed and a fleet exists, authenticate with balena login and you're ready to push a release.

We highly recommend you work through the Balena Getting Started guide for your specific device architecture (for example, Raspberry Pi 3 or Intel NUC). The setup steps — provisioning the OS, adding the device to your fleet, and the correct device type — differ by hardware, and following the wrong guide will result in a fleet your fixture cannot join.

Deployment Methods ​

There are two ways to push a new release to a balena fleet. For the Test Runner we recommend balena push.

Builds your project on the balenaCloud build servers and creates a new release for the fleet. It is independent of git, supports git submodules, and allows private base images and build-time secrets without committing them to the repository.

bash
# Authenticate (once per machine)
balena login

# Build and deploy the current project directory to a fleet
balena push <fleet-name>

Run balena push from the root of the Opal project, where the docker-compose.yml lives.

git push (CI/CD Setup Required) ​

Some fixtures pre-installed with Test Runner may have a git CI/CD pipeline set up to push to the balena fleet automatically from source code changes to the GitLab repository. This CI/CD setup requires an SSH key on a balenaCloud account that has development access to the Balena fleet to be added to the Repository Settings.

bash
git push main

The Build Process ​

When you push, the balenaCloud builder selects a build worker that matches the fleet's device architecture (native workers for ARM and AMD64 devices, qemu emulation for others) and resolves which Dockerfile to use. For the Test Runner, the docker-compose.yml defines the services that are built. Once the build succeeds:

  1. The images are uploaded to the balena registry.
  2. A release entry is created in the balena API.
  3. Every device in the fleet is notified of the release.
  4. Devices download and apply the release per the fleet's update strategy.

You can review every release — including its status, build duration, and how many devices have adopted it — on the Releases page of the balenaCloud dashboard.