From Fedora Project Wiki
Stop (medium size).png
Taskotron development reached end of life
Taskotron has been sunset in Fedora Infrastructure. It is no longer running and no longer being developed. You can use these wiki pages to learn about its history, but please be aware that the information is no longer actual.

Summary

This page describes the current state of task storage in dist-git repositories. This is not yet final thing but it is what we're starting with. Any changes to this will be announced on devel-announce before any breaking changes are put into place.

Motivation

There is a strong push for more CI-like features for testing Fedora but in order to support that, we need a way for contributors to submit tests that will scale with the number of components we have and require minimal human intervention.

People to Pester

In general, the best place to start is with the Taskotron devs who can be most easily found in the following ways:

How to write tasks

For now, all tasks will need to be written for libtaskotron. See the documentation.

Phase 1

For phase 1, the idea is to start getting tasks and tests into place The most straight-forward way to do this is to store the tests with the "code" which, in this case is the files in the rpms namespace in dist-git. For example:

rpms/foo
rpms/foo/test/
rpms/foo/test/SOME_TASK_NAME
rpms/foo/test/SOME_TASK_NAME/runtask.yml

In phase 1, all tasks will be run on build for that rpm.

Should I participate?

All folks putting tasks into dist-git during phase 1 should consider themselves "early adopters". Everything should work and documentation should be in place but we really want feedback. Are the docs not clear? Is there a missing feature that is keeping you from doing the tests you want to do? We want to know!

Why only Koji builds?

We're starting small and will continue to add features as time goes on. In future phases, this restriction will be lifted.

What about non-rpm content?

The above description should translate well to the current set of non-rpm content (docker images, modules) where the tasks in test/ are run whenever there is a build of said item.

Wasn't there a decision to use separate repos?

Yes, there was discussion around this on the devel list but this does not preclude those repos from being used. At this point, everything is opt-in and the current plan is to add separate testing repos for folks to use during a later phase.

What about collisions with that 'test' directory?

We went through all of the rpm dist-git repositories in Fedora and none of them have a 'test' subdirectory.