## Install¶

Install taskotron-runner:

sudo dnf install taskotron-runner


The runner needs write access into system-wide locations on the filesystem, and so any user who wants to run a task needs to be added to the taskotron group. Use this command command:

sudo usermod -aG taskotron <user>


Note

The user must log out and back in in order for the new group assignment to take effect.

## Run¶

Libtaskotron runner is called runtask. The basic command line has the following structure:

runtask --item <item> --type <type> <task_directory>

<item>
The subject under test, e.g. NVR of an RPM, update ID, compose ID, etc.
<type>
The type of <item>. See Special task variables for more details.
<task_directory>
The task directory needs to contain one or more ansible playbooks named tests*.yml.

Some tasks also require --arch <arch> to test a specific architecture only. See runtask --help for full commandline syntax.

Usually, you’ll see the correct input arguments in a log of an already executed tasks, so that you can easily replicate them, or an example should be mentioned in that task’s readme file.

Note

By default, runtask will attempt to execute tasks locally. Since tasks require root privileges, you either need to run runtask under the root account, or you need to have password-less sudo configured for your user account. Of course, you shouldn’t do any of this on your production machine. However, it is also possible to run the task remotely, on a different machine - see Using remote machines.

## Examples¶

task-rpmlint is a very simple task from which you can learn all the basics. Run the task like this (replace the example NVR with the build you want to test):

runtask --item htop-2.2.0-2.fc29 --type koji_build task-rpmlint/


The build will be downloaded to a local tempdir, rpmlint will be run against that build and the results will be saved in an artifacts directory (which will get printed to the console).

Note

task-rpmlint checks the whole build including all supported architectures in a single pass, so it doesn’t need --arch <arch> parameter passed in (it even ignores it). However, some tasks are arch-specific and you’ll need to specify it.

You can also see other examples.