(Created page with '{{header|qa}} {{draft}} == Introduction == This guide presumes that you have a new AutoQA test written (preferably according to Writing AutoQA Tests) and you want to ver...') |
No edit summary |
||
| Line 7: | Line 7: | ||
== Prerequisites == | == Prerequisites == | ||
You have to have [[Install and configure autotest|autotest installed] and [[Install and configure AutoQA|AutoQA installed]]. You can choose not to install and configure autotest-server (so you will use autotest-client + autoqa only) if you are willing to execute the test on your local machine. It is easier to run the test locally but you must be sure it is not destructive and there are no harmful commands that could be run by mistake (or you will be running the test on a machine that you don't have to worry about). | You have to have [[Install and configure autotest|autotest installed]] and [[Install and configure AutoQA|AutoQA installed]]. You can choose not to install and configure autotest-server (so you will use autotest-client + autoqa only) if you are willing to execute the test on your local machine. It is easier to run the test locally but you must be sure it is not destructive and there are no harmful commands that could be run by mistake (or you will be running the test on a machine that you don't have to worry about). | ||
== Examine the watcher == | |||
When you have the test ready, you have already chosen the right hook (meaning event type) for your test and added your test name to the ''testlist'' file of that hook. Now we need to simulate running the hook's watcher on AutoQA server to see what commands would be run. We can do that by adding ''--dry-run'' (use ''--help'' to see more of useful options). | |||
Let's say our test uses ''post-koji-build'' hook, which announces every package built and tagged with ''dist-fX-updates-candidate'' tag in [[Koji]]. So we would run: | |||
<pre> | |||
# /usr/share/autoqa/post-koji-build/watch-koji-builds.py --dry-run | |||
No previous run - checking builds in the past 3 hours | |||
autoqa post-koji-build --name kdemultimedia --kojitag dist-f11-updates-candidate --arch x86_64 kdemultimedia-4.3.4-1.fc11 | |||
autoqa post-koji-build --name kdeplasma-addons --kojitag dist-f11-updates-candidate --arch x86_64 kdeplasma-addons-4.3.4-1.fc11 | |||
autoqa post-koji-build --name cryptopp --kojitag dist-f12-updates-candidate --arch x86_64 --arch i686 cryptopp-5.6.1-0.1.svn479.fc12 | |||
autoqa post-koji-build --name drupal --kojitag dist-f12-updates-candidate --arch x86_64 drupal-6.15-1.fc12 | |||
autoqa post-koji-build --name espeak --kojitag dist-f12-updates-candidate --arch x86_64 --arch i686 espeak-1.42.04-1.fc12 | |||
autoqa post-koji-build --name seamonkey --kojitag dist-f12-updates-candidate --arch x86_64 --arch i686 seamonkey-2.0.1-1.fc12 | |||
... output trimmed ... | |||
</pre> | |||
These all tests would be run, some on a single architecture, some on multiple architectures. We will pick one of them to try our new test on it. Let's say we'll try espeak line. | |||
Revision as of 15:29, 17 December 2009
It is still under construction and content may change. Do not rely on the information on this page.
Introduction
This guide presumes that you have a new AutoQA test written (preferably according to Writing AutoQA Tests) and you want to verify that it works ok. This article will show you how to do it.
Prerequisites
You have to have autotest installed and AutoQA installed. You can choose not to install and configure autotest-server (so you will use autotest-client + autoqa only) if you are willing to execute the test on your local machine. It is easier to run the test locally but you must be sure it is not destructive and there are no harmful commands that could be run by mistake (or you will be running the test on a machine that you don't have to worry about).
Examine the watcher
When you have the test ready, you have already chosen the right hook (meaning event type) for your test and added your test name to the testlist file of that hook. Now we need to simulate running the hook's watcher on AutoQA server to see what commands would be run. We can do that by adding --dry-run (use --help to see more of useful options).
Let's say our test uses post-koji-build hook, which announces every package built and tagged with dist-fX-updates-candidate tag in Koji. So we would run:
# /usr/share/autoqa/post-koji-build/watch-koji-builds.py --dry-run No previous run - checking builds in the past 3 hours autoqa post-koji-build --name kdemultimedia --kojitag dist-f11-updates-candidate --arch x86_64 kdemultimedia-4.3.4-1.fc11 autoqa post-koji-build --name kdeplasma-addons --kojitag dist-f11-updates-candidate --arch x86_64 kdeplasma-addons-4.3.4-1.fc11 autoqa post-koji-build --name cryptopp --kojitag dist-f12-updates-candidate --arch x86_64 --arch i686 cryptopp-5.6.1-0.1.svn479.fc12 autoqa post-koji-build --name drupal --kojitag dist-f12-updates-candidate --arch x86_64 drupal-6.15-1.fc12 autoqa post-koji-build --name espeak --kojitag dist-f12-updates-candidate --arch x86_64 --arch i686 espeak-1.42.04-1.fc12 autoqa post-koji-build --name seamonkey --kojitag dist-f12-updates-candidate --arch x86_64 --arch i686 seamonkey-2.0.1-1.fc12 ... output trimmed ...
These all tests would be run, some on a single architecture, some on multiple architectures. We will pick one of them to try our new test on it. Let's say we'll try espeak line.