As discussed in https://pagure.io/releng/failed-composes/issue/6538
we noticed a gap in openQA coverage here. We don't check the
versions of packages lorax installs to the installer environment,
and those packages do not make it to the installed system, so if
there's a dep issue that prevents a package in the update from
being included in the installer environment, but the same dep
issue isn't caught on any other path, we miss the problem. This
wires the updvercheck.py script into the _installer_build and
_ostree_build tests to catch this kind of problem, and makes it
capable of parsing pylorax.log files into its preferred format
to enable that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In the "installed package is newer than the one in the update"
case, also be OK (soft fail) if the update is obsolete, not just
if it's stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
With Rawhide updates, we quite often run into a situation where
a test runs after a *later* version of the package has already
gone stable. This even happens for stable releases too, though
less often. The current shell-based check just always fails on
this case, but it's usually OK, and manually marking every case
like this with an "it's OK!" comment gets tiring. Instead, let's
use a smarter Python script to do the check. We compare the EVR
of all installed update packages with the EVR of the package
from the update. If it's the same, fine. If the installed package
is lower-versioned, that's always an error, and we fail. If the
installed package is higher-versioned, we check whether the
update already went stable. If it did, then we soft fail, because
probably nothing can go wrong at this point (this is the usual
Rawhide case). If the update did not yet go stable, we still
hard fail, because something can go wrong in this case: if the
update *now* goes stable, the older version from the update may
be tagged over the newer version the test got (presumably from
current stable).
If anything goes wrong with the Bodhi check, or the test is
running on a task not an advisory, we treat both cases as fatal.
The script also gives easier-to-understand output than the old
approach, which should be a bonus.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
