add 32-bit tests to templates
ClosedPublic

Authored by adamwill on Aug 13 2015, 10:00 PM.

Details

Summary

This duplicates basically the entire test suite for 32-bit. We
could choose to run only a few tests for 32-bit if we wanted,
but I figure we may as well do as much testing as we can. Only
a few of the results will actually wind up 'counting' separately
in the wiki, but we can always see the results for all the tests
in openQA itself.

Next we can duplicate the whole set again for UEFI!

Test Plan

Schedule a full test run and make sure all the tests
run for both arches. Also check result submission works
correctly. Requires the corresponding change to tools (or
you can just use one of the trigger commands which lets you
specify arch with a parameter).

Diff Detail

Repository
rOPENQATESTS os-autoinst-distri-fedora
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 add 32-bit tests to templates.Aug 13 2015, 10:00 PM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)
adamwill added reviewers: jskladan, garretraziel.
garretraziel accepted this revision.Aug 14 2015, 6:56 AM

This LGTM. How long does it take to finish whole suite now? I'm not against scheduling whole testsuite for both architectures, but I hope that we won't get to the point where results will be ready more than a day behind compose. I think that we should investigate possibility to upload test results to wiki ASAP (and not after all tests finish).

This revision is now accepted and ready to land.Aug 14 2015, 6:56 AM

I don't know how long coconut takes; on colada the whole set takes ~45 mins with this change. We definitely can trim the set down a bit, maybe I'll do that on commit.

When we decided whether tests needed to be run for multiple arches for the wiki we tried to factor tester time into account, so I think just running the tests that will actually show up as separate results in the wiki would be cutting too far: there are some tests where testing both arches would provide some value but the wiki doesn't expect it because we just didn't want to overload some people. But it really isn't necessary to run all the partitioning tests twice, probably, for instance. I'll take a look at it before I merge.

This revision was automatically updated to reflect the committed changes.

I decided to just go ahead and merge as-is: I figured we can use running all the tests as a base, and if it turns out to be a problem (taking too long to run the tests, or whatever) we can easily just adjust from there, taking out ones that make the least sense to run for both arches as needed.