From Fedora Project Wiki

Revision as of 21:09, 24 August 2009 by Wwoods (talk | contribs) (Partial first draft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

AutoQA is an automated test system for Fedora. Its basic design is simple: when certain events occur (a package is built, updates are pushed, a new Rawhide build is available, etc.) autoqa launches some automated tests.

Events and Hooks

For AutoQA to respond to an event, someone needs to write a "hook" for that event. The first step in creating a new hook is, obviously, to define the event it responds to.

For example, the post-repo-update hook is triggered whenever a Fedora repo is updated. Obviously, any test that will run in response to this event will need to know the URL of the repo that was just updated. (This is a required argument.) Certain repos can't be used properly without other "parent" repos (for example, the Fedora 11 updates repo isn't useful without also knowing the address of the main Fedora 11 repo). So a list of "parent repos" is an optional argument to the tests.

The hooks/ directory in the autoqa source tree contains the hooks that AutoQA knows about. A hook has five main parts:

  1. README
    • describes the event itself and the required (and optional) arguments that will be passed along to the tests.
  2. hook.py
    • python code that is used to parse the test arguments, as described in the README file. This is the formal definition of the test arguments.
  3. testlist
    • contains the list of test names that will be launched when this hook is triggered.
  4. control.template and test_class_template.py
    • generic templates for creating new tests that use this hook. See below for more information on writing new tests.
  5. Watcher
    • This is the code that watches for the event and launches the autoqa harness with the arguments described in README and hook.py.
    • Currently, all existing watchers are scripts that get run periodically by crond to check to see if the event has occurred since the last time it was run. If so, it launches autoqa.
    • In the future this will change to a daemon that waits for notifications about the event - see the Messaging SIG's Publish Subscribe Notification Proposal for further info about that.

Detailed information about implementing new hooks will be found in Writing AutoQA Hooks.

The autoqa Harness

The autoqa harness is launched by the watchers in response to an event.