If you're a Fedora package maintainer, you will be surely interested in this topic.
AutoQA [1] is a framework for automatic test execution written for Fedora needs. It is developed by Fedora QA [2] team. We have finally reached the state where we can experimentally share some tests results with the wide public. They were already available in the autoqa-results [3] mailing list, but that's not really what we mean by public consumption. Let's improve that.
Now prepare the drums... ready?... we are going to post the results into Fedora Update System [4] (a.k.a. Bodhi)!
After you propose an update in Bodhi (either to -updates or to -updates-testing), you will start receiving AutoQA results as Bodhi comments.
Example comment: http://kparal.files.wordpress.com/2011/03/bodhi-comment.png
A few very important notes:
* The test results are purely *informative*. We won't block/reject your updates if they fail some test. But we hope that you (or RelEng team members) will have a look at the issue and it will help you/them to decide whether it is ok to push this update or not.
* The two tests which will be executed (described below) are designed to check for issues that don't offer too much speculation. We don't want new updates to break the dependencies, ever. We want new updates to keep upgradepath constraint, always. If the result is _failed_, there is either a problem in the update or a problem in our test. If you believe the latter is the case, please, report the problem to us - AutoQA [1], autoqa-devel [5]. Those tests are very complex and there is at least one bug in every program. We know that it will be a bumpy road until we have them perfect.
* It's very easy to disable Bodhi comment posting if something goes really wrong. We will probably do that if we discover some serious issue and re-enable it again after we fix it. So don't be afraid, we won't flood your inbox (the doomsday is not until 2012, you know), and also don't be surprised if the comments don't arrive sometimes.
There are two tests whose results will be posted to Bodhi:
* depcheck [6] - This test checks the dependencies (provides/requires/conflicts/obsoletes flags) of the proposed packages coming into -updates or -updates-testing. It tries to decide whether your update would break the repository (i.e. some packages would have unresolved dependencies in that case). There's a lot of very complex logic behind it.
* upgradepath [7] - This test checks whether the _upgradepath_ requirement is fulfilled. In an example with Fedora 13 and package foo-1.1-1.fc13 it means that every higher Fedora release (14, 15, 16) must contain same or higher NVR of the foo package than is the currently proposed one (and vice versa for lower Fedora releases). This constraint is currently checked only for -updates repository requests.
Next to every result you'll see an URL pointing to the full results log. You'll want to inspect that if your package was marked as failing some test. Example URL:
http://autoqa.fedoraproject.org/results/70273-autotest/qa03.c.fedoraproject....
The results directory is currently a little bit chaotic, but the important files are:
* <testname>/results/output.log where you'll see a shortened output of the test with important highlights as the first lines
* debug/client.DEBUG contains full debug log as created by the framework
In those files you should be able to find the reason why your package failed the test (search for your NVR).
The tests are executed fairly often (almost for every update request), which means that after you correct the problem (if there was any), you should quickly receive another comment saying that your package now passes the test. If your package fails again however, you won't receive another comment - we don't want to spam you with Bodhi notification emails too often. Currently we wait at least three days before inserting two subsequent _fail_ comments.
Feedback/comments welcome.
[1] https://fedoraproject.org/wiki/AutoQA [2] http://fedoraproject.org/wiki/QA [3] https://fedorahosted.org/pipermail/autoqa-results/2011-March/thread.html [4] https://admin.fedoraproject.org/updates/ [5] https://fedorahosted.org/mailman/listinfo/autoqa-devel [6] https://fedoraproject.org/wiki/QA:Depcheck_Test_Case [7] https://fedoraproject.org/wiki/QA:Upgrade_Path_Test_Case
On Mon, Mar 21, 2011 at 14:16:34 -0400, Kamil Paral kparal@redhat.com wrote:
Feedback/comments welcome.
Thanks!
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
Rich.
On Mon, Mar 21, 2011 at 18:49:21 +0000, "Richard W.M. Jones" rjones@redhat.com wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
From the following message:
http://lists.fedoraproject.org/pipermail/devel-announce/2010-June/000620.htm...
1. Login to fedorapeople.org # ssh fedorapeople.org 2. Run the command: autoqa-optin <package> [<release>]
On Mon, 2011-03-21 at 18:49 +0000, Richard W.M. Jones wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
There's some pretty good documentation on this here:
https://fedoraproject.org/wiki/Writing_AutoQA_Tests
that explains the mechanics of autoqa tests; you'd write a test, then wrap it for autoqa according to the instructions there, then propose on autoqa-devel that it be added into fedora's autoqa setup.
On Mon, 2011-03-21 at 18:49 +0000, Richard W.M. Jones wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
Hey Richard,
We also aren't yet setup to provide disposable test environments. Which means, all tests currently share a pool of test systems and we monitor the tests to ensure they are playing nice. We could certainly use some help to figure out a way to dynamically create test systems on the fly so maintainers can start adding their own tests.
Thanks, James
On 03/21/2011 12:26 PM, James Laska wrote:
On Mon, 2011-03-21 at 18:49 +0000, Richard W.M. Jones wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
Hey Richard,
We also aren't yet setup to provide disposable test environments. Which means, all tests currently share a pool of test systems and we monitor the tests to ensure they are playing nice. We could certainly use some help to figure out a way to dynamically create test systems on the fly so maintainers can start adding their own tests.
%check (in your .spec) still works in the meantime for anything that should prevent shipping a build.
On Mon, 2011-03-21 at 12:30 -0700, Christopher Aillon wrote:
On 03/21/2011 12:26 PM, James Laska wrote:
On Mon, 2011-03-21 at 18:49 +0000, Richard W.M. Jones wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
Hey Richard,
We also aren't yet setup to provide disposable test environments. Which means, all tests currently share a pool of test systems and we monitor the tests to ensure they are playing nice. We could certainly use some help to figure out a way to dynamically create test systems on the fly so maintainers can start adding their own tests.
%check (in your .spec) still works in the meantime for anything that should prevent shipping a build.
Excellent point. Note, there are some environmental differences between running %check tests in a build environment vs a test environment. But it's certainly better than nothing.
Thanks, James
On Mon, Mar 21, 2011 at 12:30:53PM -0700, Christopher Aillon wrote:
On 03/21/2011 12:26 PM, James Laska wrote:
On Mon, 2011-03-21 at 18:49 +0000, Richard W.M. Jones wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
Hey Richard,
We also aren't yet setup to provide disposable test environments. Which means, all tests currently share a pool of test systems and we monitor the tests to ensure they are playing nice. We could certainly use some help to figure out a way to dynamically create test systems on the fly so maintainers can start adding their own tests.
If only there was a way to prepop virtual machines on the fly :-)
%check (in your .spec) still works in the meantime for anything that should prevent shipping a build.
It's just that libguestfs's %check takes ~2 hours to run on Koji :-(
Rich.
On Mon, 2011-03-21 at 19:54 +0000, Richard W.M. Jones wrote:
On Mon, Mar 21, 2011 at 12:30:53PM -0700, Christopher Aillon wrote:
On 03/21/2011 12:26 PM, James Laska wrote:
On Mon, 2011-03-21 at 18:49 +0000, Richard W.M. Jones wrote:
How can I add tests for my package to Fedora AutoQA, eg. so that they run (say) each time I build the package in Koji?
(Note: I'm not asking how to run an AutoQA server myself.)
Hey Richard,
We also aren't yet setup to provide disposable test environments. Which means, all tests currently share a pool of test systems and we monitor the tests to ensure they are playing nice. We could certainly use some help to figure out a way to dynamically create test systems on the fly so maintainers can start adding their own tests.
If only there was a way to prepop virtual machines on the fly :-)
Exactly! Anyone with experience/skills in this space ... please join autoqa-devel@lists.fedorahosted.org and share your ideas. I don't think we've fully articulated our needs in this space yet, but I'm interested in seeing what cloud-like options are available and can be used.
%check (in your .spec) still works in the meantime for anything that should prevent shipping a build.
It's just that libguestfs's %check takes ~2 hours to run on Koji :-(
Yeah, certainly not fun to hold up the build system for that.
Thanks, James