Taskotron Quick Start¶
Install¶
Install libtaskotron
:
sudo dnf install libtaskotron
See libtaskotron modules for more information on installing individual modules.
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.0.2-4.fc27 --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.