A little thing I’ve been working on lately finally went live today…this thing:
Several weeks ago now, I adapted Fedora’s openQA to run an appropriate subset of tests on critical path updates. We originally set up our openQA deployment strictly to run tests at the distribution compose level, but I noticed that most of the post-install tests would actually also be quite useful things to test for critical path updates, too.
First, I set up a slightly different openQA workflow that starts from an existing disk image of a clean installed system, downloads the packages from a given update, sets up a local repository containing the packages, and runs
dnf -y update before going ahead with the main part of the test.
All of this went into production a few weeks ago, and the tests have been run on every critical path update since then. But there was a big piece missing: making the information easily available to the update submitter (and anyone else interested). So I wanted to make the results visible in Bodhi, alongside the Taskotron results. So I sent a patch for Bodhi, and the new Bodhi release with that change included was deployed to production today.
Now the results are retrieved in a much more efficient manner and shown on a separate tab, where a count of the results is displayed once they’ve all been retrieved.
So with Bodhi 2.6, you should have a much more pleasant experience viewing automated test results in Bodhi’s web UI – and for critical path updates, you’ll now see results from openQA functional testing as well as Taskotron tests!
At present, the tests openQA runs fall into three main groups:
Some simple ‘base’ tests, which check that SELinux is enabled, service manipulation (enabling, disabling, starting and stopping services) works, no default-enabled services fail to start, and updating the system with
Some desktop tests (currently run only on GNOME): launching and using a graphical terminal works, launching Firefox and doing some basic tests in it works, and updating the system with the graphical updater (GNOME Software in GNOME’s case) works.
Some server tests: is the firewall configured and working as expected, is Cockpit enabled by default, and does it basically work, and both server and client tests for the database server (PostgreSQL) and domain controller (FreeIPA) server roles.
So if any of these fail for a critical path update, you should be able to see it. You can click any of the results to see the openQA webUI view of the test.
Right now there’s an issue causing all the desktop tests to fail for Fedora 26 updates; the behaviour of the base image changed unexpectedly when it was regenerated recently (gnome-initial-setup no longer runs on login). I’m looking into this and hope to have it resolved soon.
At present you cannot request a re-run of a single test. We’re thinking about mechanisms for allowing this at present. You can cause the entire set of openQA tests to be run again by editing the update: you don’t have to add or remove any builds, any kind of edit (just change a character in the description) will do.
If you need help interpreting any openQA test results, please ask on the test@ mailing list or drop by #fedora-qa . Myself or garretraziel should be available there most of the time.
Please do send along any thoughts, questions, suggestions or complaints to test@ or as a comment on this blog post. We’ll certainly be looking to extend and improve this system in future!
Source From: fedoraplanet.org.
Original article title: Adam Williamson: Automated critical path update functional testing for Fedora.
This full article can be read at: Adam Williamson: Automated critical path update functional testing for Fedora.