Tasks provided with Beaker

Besides the custom tasks which Beaker users would write for a specific testing scenario, there are a number of tasks which are distributed and maintained along with Beaker. Among these, the /distribution/check-install, /distribution/install, and /distribution/reservesys tasks are essential for Beaker’s operation. The /distribution/inventory task is not essential for Beaker’s operation, but it is required for accurate functioning of Beaker’s ability to schedule jobs on test systems meeting user specified hardware criteria. The /distribution/beaker/dogfood task runs Beaker’s test suite (hence, the name dogfood) and is perhaps only useful for meeting certain specific requirements of the Beaker developers.


The purpose of this task is to report back on the system install (provisioning). It is usually added before any scenario specific tasks so that it is run immediately after the system has been provisioned.

This task collects and reports various information about the installed system which may be useful in debugging any problems with the installer or the distro.


This task is deprecated. Use /distribution/check-install instead.

This is the original implementation of the installation checking task, but its name has proved confusing, and it carried a very large (and unnecessary) set of package requirements for historical reasons.

This task is still maintained for backwards compatibility. Note that the bkr workflow commands will schedule this older task (instead of its replacement /distribution/check-install) for recipes running Fedora 28 and older, or RHEL7 and older.


The /distribution/reservesys task reserves a system for a specific time frame to aid post-test analysis. You would usually append this task in your recipe so that the system is available for you to login after the other tasks have been run, but before the system is returned to Beaker. Reserving a system after testing describes system reservation in detail.


The /distribution/inventory task is useful for the administrator of a Beaker installation to gather detailed hardware data about Beaker’s test systems. Hardware devices which are probed include disk drives, graphics hardware and network devices. When this task is run on a test system, it retrieves this information and sends it to the Beaker server where it is updated in the main database.

This data can then be used by Beaker to schedule a job for which a specific hardware requirement may have been specified (See: device specification in jobs). Hence, it is a good idea to run this task on every system to ensure that the hardware details are correctly updated in Beaker’s database.


The /distribution/command task runs an arbitrary shell command, given in the CMDS_TO_RUN parameter.

This task is useful for inserting ad hoc tests or behaviour into a recipe for experimentation purposes, without needing to modify an existing task or write a new one.

For example, to test the effect of rebooting in between two other tasks:

<task name="/distribution/command">
        <param name="CMDS_TO_RUN" value="rhts-reboot" />


The /distribution/beaker/dogfood task runs Beaker’s test suite (unit tests and selenium tests) on a test system. It can be configured to either run the tests from the development branch of Beaker or the most recent released version.

This task is used by the Beaker developers to run the test suite every time a new patch is pushed to the development branch to help prevent any regressions in the code base.


This is a placeholder task used to align task execution across different recipes in a multi-host recipe set. See Multihost tasks for details.


The /distribution/virt/install task is responsible for installing a virtual machine (defined as a ‘guest recipe’ in Beaker). It does this via virt-install. The task is defined in the host recipe, often along with /distribution/virt/start. For example:

<task name="/distribution/check-install" role="SERVERS">
<task name="/distribution/virt/install" role="SERVERS">
<task name="/distribution/virt/start" role="SERVERS">

Be aware that /distribution/virt/start and /distribution/virt/install should never be defined in the guest recipe itself.


This task is an experimental alternative to the regular /distribution/virt/install task for installing guest recipes. Rather than booting the installer inside the guest and running through a complete installation, this task fetches a cloud image and boots that.

The CLOUD_IMAGE task parameter should be the URL for a suitable cloud image. The image must have the cloud-init package pre-installed and enabled. This task approximates the effect of the guest kickstart by generating a suitable user-data file for cloud-init.

Note that there are a number of limitations when using this task:

  • The distro tree selected by Beaker for the guest recipe is effectively ignored. The distro used in the guest is determined solely by what image is given.
  • Similarly, it is the job submitter’s responsibility to use a suitable local mirror for the cloud image. (Fetching the image over an expensive WAN link is not desirable but Beaker will not prevent it.)
  • Not all parts of the guest kickstart are accurately applied, since the installer is skipped. The task extracts %packages and %post sections, and it also handles the repo, rootpw, and selinux commands.


The /distribution/virt/start task is used for starting a virtual machine, via virsh start. Please see /distribution/virt/install for examples on how to use it with /distribution/virt/install.


This task is for experimental mass rebuilds of an entire distribution from source, for example using a newer or modified build toolchain. It fetches source RPMs from a given yum repo and rebuilds them all in mock.

Packages are rebuilt in alphabetical order. This task does not attempt to build packages in dependency order, nor does it inject the build results back into the build root.

The following task parameters are accepted:

URL of the yum repo to fetch source RPMs from.
Space-separated list of URLs of the yum repos to include in the build root. Typically this should include the entire distribution or the build tag for it. You can also add extra repos containing patched packages.
Command to be run when mock sets up the chroot. The default value is suitable for Fedora: install @buildsys-build. The group name may need adjusting for other distros.
Target architecture for builds. By default this will match the arch of the recipe where this task is running.
Name of the mock configuration to use or generate (excluding .cfg file extension). If this parameter is set and the configuration exists, it will be used as is. Otherwise the configuration will be generated based on the parameters above.
If set to a non-empty value, skip building any SRPMs which produce only noarch packages.
If set to a non-empty value, keep the results (RPMs and log files) produced by each build in /mnt/tests/distribution/rebuild/results/packagename/. You can use a subsequent task in the recipe to examine the results or copy the RPMs elsewhere.
SRPMs to skip. This parameter must be a whitespace-separated list of bash glob patterns. Each pattern is matched against the SRPM filename (including .src.rpm extension). If any pattern matches, the SRPM is skipped. For example kernel* will skip any SRPMs beginning with kernel.
SRPMs to build. If this parameter is set, any SRPM which does not match a pattern in the whitelist is skipped. Similar to SRPM_BLACKLIST, this must be a whitespace-separated list of bash glob patterns.

As an example, imagine you have built the latest GCC version 99.0, and you want to try rebuilding all architecture-specific packages in Fedora 21 using the new compiler to see if it introduces any build failures:

<task name="/distribution/rebuild" role="STANDALONE">
        <param name="SOURCE_REPO"
               value="" />
        <param name="MOCK_REPOS"
            " />
        <param name="SKIP_NOARCH" value="1" />

Other tasks

There are a number of other tasks that you will find in the Tasks/ sub-directory of the Beaker source tree. Most of these tasks (besides the ones we discussed above), have a PURPOSE file which contains a brief description of what the task does.