New Taskotron Tasks

For a while now, we, Fedora QA, have been busy with building Taskotron core features and didn’t have much resources for additions to the tasks that Taskotron runs. That changed a few weeks back when we started running task-dockerautotest, task-abicheck and task-rpmgrill tasks in our dev environment. Since we have been happy with the results of having run those tasks, we deployed them to the production instance as well last week. Please note that the results of those tasks are informative only. Lets introduce the tasks briefly:


Task-dockerautotest is the first package-specific task that Taskotron runs. It is triggered on each completed docker build in Koji. Please note that we wrote only the taskotron wrapper for the dockerautotest test suite. The test suite’s git repo can be found here and the task’s git repo here.


Task-abicheck looks for incompatibilities in ABI between two versions of a package. The task is run only on a subset of packages in Fedora. Currently we run the task on a subset (we exclude firefox, thunderbird, kernel, kdelibs, kdepim and qt) of packages from critpath. The reason we limit packages we run the task on, for now, is due to memory consumption the task needs for some packages. Each time a build of a package from critpath is completed in Koji task-abicheck is run and compares ABIs of the build and its previous version. Kudos to Dodji Seketeli for the work on libabigail and Sinny Kumari for writing the task! The task’s git repo can be found on pagure.


Task-rpmgrill is run each time a build is completed in Koji and performs a set of analysis tests on all RPMs built from the build’s source RPM. The task expands capabilities of task-rpmlint with build log analysis or ELF checks, to name a few. Kudos to Ralph Bean for writing Taskotron wrapper for the task! The task’s git repo can be found here.

Looking at the task results

If you are interested in looking at the new tasks results, you can do so via ResultsDB frontend.

Glorious future

Recently, Miro Hroncok sent a review request for “Python Version Check” which we are planning to review and deploy in the not so distant future. We are also looking for “guinea pigs” to write package-specific tasks so we can test our upcoming feature, dist-git style tasks. If you have a task (or an idea of), either generic or packages-specific and want to run it in Taskotron, please do reach to us.

Receiving notifications about results

If you wish to receive notifications about any of new tasks results of you package, you can do so in FMN. If you are not sure how to set up notifications, my previous post on that topic should help with that.

Found an issue?

As usual, if you hit any issues and/or have any questions or suggestions, don’t hesitate to contact us either in #fedora-qa on Freenode IRC or on qa-devel mailing list. You can also file bugs or send RFE in our Phabricator instance.

Taskotron Results Notifications

With Taskotron not sending comments to Bodhi anymore, there was no easy way to be notified about task results. This changed about a month ago when Taskotron started emitting fedmsgs so results started arriving to packagers. Last week, we fine-tuned notifications so packagers have more power over what result notifications they receive. Let’s have a look what are the defaults and what you can do to change them to suit your needs.

The default FMN Taskotron filter looks like this:taskotron-filter
What this means is that by default anytime depcheck or upgradepath tasks run on a package you have either commit ACLs on or the watchcommits flag, and the result (outcome) is either FAILED or has changed from the previous run, you get notified (on irc, email or both depending on how you set your FMN) about the result.

Let’s have a look at an example of a notification that maintainers of puppet got recently:

upgradepath FAILED for puppet-4.2.1-1.fc23

The notification is pretty straight-forward, saying that the package failed upgradepath task and contains a log with details.

If one wants to receive different set of notifications, there are two options: a) add/remove rules in the default Critical taskotron tasks on my packages filter, b) create a new filter. Let’s have a look at couple of filters that some might find useful.

Let’s say one is satisfied with the default filter but wants to receive notifications about rpmlint task in addition to release-critical tasks. This can be done by omitting Release-critical taskotron tasks rule, so the filter would look like this:


Other use case could be that maintainer wants to receive notifications even when tasks pass. The following filter allows maintainers to receive notifications for any task with any outcome:


If there are any more use cases, the following set of rules is available to add to filters:


If you hit any issues or have any questions and/or suggestions, don’t hesitate to contact us either in #fedora-qa on Freenode IRC or on qa-devel mailing list. You can also file bugs or send RFE in our Phabricator instance.