Update testing: log packages in update and installed packages
ClosedPublic

Authored by adamwill on Feb 22 2017, 11:36 PM.

Details

Summary

This adds some logging related to the update testing workflow,
so we have some idea what we actually tested. We log precisely
which packages were actually downloaded from the update - this
is important as updates can be edited and when examining results
we'll want to know which packages actually got used. We also
add a new module which runs at the end of postinstall and tries
to figure out which packages from the update were installed in
the course of the test. This still isn't a guarantee the test
actually *tested them* in any way, but it at least means they
got installed successfully and didn't interfere with the test.

Test Plan

Run the update test workflow, check the logs get
uploaded and seem accurate (sometimes some RPM garbage messages
wind up in the package log, I'm not too worried about that at
present). Run the compose test workflow and check it didn't
break.

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 Update testing: log packages in update and installed packages.Feb 22 2017, 11:36 PM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)
adamwill added a reviewer: jsedlak.
jsedlak accepted this revision.Feb 23 2017, 12:39 PM

It works without problem.

As a side-note maybe we could come up with basic tests for critpath packages so that we could test something more than "yup, it still boots even with this update installed".

Anyway, great work!

This revision is now accepted and ready to land.Feb 23 2017, 12:39 PM

well, the tests we run cover *most* of the critpath functionality. I dunno how far I wanna go adding tests on this path, especially covering ground we could cover with Taskotron tests, but hey, why not. :) We *could* add a test that just does "dnf install *.rpm", I was thinking about that.

I'm working on the scheduler side ATM, didn't have enough bits ready to send a diff yesterday though.

This revision was automatically updated to reflect the committed changes.