It's been a while since I've written anything about Taskotron and we've been pretty quiet in general, so it's about time that changed. There will be more posts about Taskotron details in the next several weeks but this one is more of an overview.
We made our first release last week but what does this mean? It's mostly an indication of a change in development process for us. Instead of the feature-based releases that we were originally planning, we're moving to a time-based schedule with a two week release cadence. The current plan is still to replace AutoQA for Fedora 21 and we're being cautious to minimize disruptions to what folks are already used to.
libtaskotron is mostly working as of the 0.1 release - it's still in an early alpha state (expect changes to any tasks which work with 0.1) and there is still work to be done before we're ready to replace AutoQA and start adding more exciting features. If you're interested in seeing a concrete demonstration of where we're going, check out our task writing guide.
For even more information, check out the following links:
Questions and Answers
From conversations that I've had with various people, I'm under the impression that there are quite a few questions and misunderstandings about what Taskotron is and what direction we're going in. While incomplete, I wanted to answer some of the most common questions.
What does Taskotron do?
The short answer is "allows for automating tasks" and while that's so vague that it's almost useless, it's relatively accurate. Taskotron is a system designed to facilitate the automation of tasks (not limited to what is usually referred to as "test automation") which is made up of multiple components
- A runner and support libraries for executing tasks. If you're interested in using Taskotron to automate something, the libtaskotron docs are likely a good place to start.
- Listens for fedmsgs and causes the execution engine to schedule relevant jobs with information from the received fedmsg (e.g. schedule upgradepath when a bodhi update is changed or some package-specific task foobar when foo is built successfully)
- A restful interface designed to hold data from task execution in the Taskotron system. Commonly used in combination with a web interface for human interface.
- Execution Engine
- The current Taskotron deployment uses buildbot and while we have no current plans to migrate away from using builbot, Taskotron is not completely tied using it.
These components work together to make the whole Taskotron service but a majority of the work that folks are interested in is done by libtaskotron
How do I set up a Taskotron instance?
Our ansible playbook repository is a good place to start if you're really looking to do. However, the only times that you'll need a full Taskotron deployment is if you're writing interaction code for one of the Taskotron components, need to test the full system for non-task code you've written or are deploying a Taskotron instance instead of using an already available instance.
libtaskotron was designed to work as a standalone runner. One of my pet peeves about AutoQA was that it required a full installation (mysql, httpd, autotest service) to write tests and even more services if you wanted to work on the system. If you ever find yourself in a situation where you need a full stack to write a task, please come find me or another Taskotron dev because there was almost certainly a misunderstanding, something wrong in the documentation or a bug in libtaskotron.
When is feature X going to be done?
Unless that feature fits into our immediate priority of replacing AutoQA with a solid base system we can build on, the short answer is that I don't know. There are several directions that we could go in after replacing AutoQA and I'm expecting many feature requests in the next several weeks. As we get closer to deploying a production system, we'll have a more precise answer.