rework wiki report 'conditions', for notification tests
ClosedPublic

Authored by adamwill on Sep 30 2016, 12:19 AM.

Details

Summary

The big change here is a rework of how 'advanced' entries in
conf_test_suites TESTSUITES work. To report the notification
test results we need to allow for this logic: 'report a pass
for wiki test X only if both testsuite A and testsuite B
passed' - neither desktop_notifications_live passing on its
own nor desktop_notifications_postinstall passing on its own
fully covers any of the wiki test cases, but if *both* pass,
then two of the wiki test cases are covered.

I wanted a consistent and vaguely understandable syntax for
expressing this, so I incorporated a rework of the existing
complex case - 'report a pass only if specific openQA test
modules pass' - into this too. Thus the layout of the dicts
used in the 'complex' case is changed so it's less specific
to the 'module' case. The dicts now use test case names as
their keys and dicts of 'conditions' that must be satisfied
for a pass to be reported as the value for each key. An empty
'conditions' dict just means the same as the 'basic' format:
report this test case as passed if the job passed.

Otherwise, the dict can specify various different types of
conditions that must be satisfied *as well as* the job passing
before a wiki pass will be generated for that wiki test case.
Currently there are 'modules' and 'testsuites' conditions, but
with this design we could add more if needed. The 'modules'
value is an iterable of openQA job modules which must have
passed within the job for a wiki pass to be generated; the
'testsuites' value is an iterable of other test suite names,
each of which must have passed for the same openQA BUILD,
MACHINE and FLAVOR for a wiki pass to be generated.

We adjust the FreeIPA tests to the new design, add entries for
the notifications tests using the new design, and adjust
report.get_passed_testcases to do the work. We fix and update
some comments, and split the now-quite-long code for parsing
the TESTSUITES dicts into its own function, just to make things
a bit more readable.

We also adjust checkwiki for the changed design, enhance it
to handle the 'testsuites' condition and run some specific
checks for it, enhance it to check that all 'modules' named in
a condition are present in the openQA distri (as I realized
that's a check that was missing), and refactor it into separate
test functions, as the giant main() was getting unwieldy,
hard to follow, and increasingly likely to suffer some kind of
variable scope issue.

Test Plan

Use checkwiki and mess around with conf_test_suites
a bit, generate results for a test run that has passed FreeIPA
and notifications tests and make sure you get appropriate
ResTups. I tested reporting the 20160927.n.0 results with this
code and you can see it worked:
https://fedoraproject.org/wiki/Test_Results:Fedora_25_Branched_20160927.n.0_Desktop
It'd probably be good to somehow force a case where one of the
notifications tests passed but the other failed, and check we
do *not* report a pass in this case (fake up the jobs or just
find a compose where that happened or whatever).

Diff Detail

Repository
rOPENQA fedora_openqa
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
adamwill retitled this revision from to rework wiki report 'conditions', for notification tests.Sep 30 2016, 12:19 AM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)
adamwill added reviewers: jskladan, garretraziel.
garretraziel accepted this revision.Oct 3 2016, 11:47 AM

ACK, but please, see inline comments.

scheduler/fedora_openqa_schedule/report.py
127

This try: except is way too long. I think that it would be better to use if isinstance, for example:

if isinstance(testsuite, list):
    return testsuite
... # code from try: except block
139

Use True/False instead of 1.

147

Switch not module.get() in to module.get() not in.

This revision is now accepted and ready to land.Oct 3 2016, 11:47 AM
adamwill added inline comments.Oct 3 2016, 3:55 PM
scheduler/fedora_openqa_schedule/report.py
127

I generally dislike using isinstance in that way, as it's really artificially limiting; it prevents the use of any other iterable. I mean, I guess we *could* use it here since we control the data structure it's reading from pretty tightly, but it still just rubs me the wrong way. I'll see if I can come up with a better solution.

139

hah, too much perl...

This revision was automatically updated to reflect the committed changes.

Addressed all three issues in landed version, thanks.