Instead of just redirecting it to a log file, let's tee it, so
simple errors can be read off a screenshot without bothering to
download the file. Also, let's timestamp it (via `ts` from
moreutils) so we can see which bits of it take a long time...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think these needles are pretty fragile to changes in the
underlying OSM dataset, not just in Maps itself...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Also use get_var("TEST") for installer_build - no point trying
to upload these logs for the other tests in the same flavor,
they won't be there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It doesn't make sense for update tests to have different
priorities. We gate on all update tests, so they are all equally
important. With varying priorities we get a problem: if 10
updates are created quite close together, first we do all the
prio 30 and prio 40 tests for all of them, and only after all of
those are done do we get to the prio 41 and 42 tests for the
earliest of the updates, which means they can be waiting longer
than they should to have all the tests done. If all the tests
have the same priority, openQA should always use creation time
to order them, so it should prioritize finishing tests for
earlier updates, which is what we want.
Update tests are also more time-critical than compose tests,
because we gate on update tests. So we should prioritize update
tests over compose tests in all cases.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is intended to allow us to split the workload across
multiple tap workers, as right now, sometimes we wind up in a
situation where all non-tap jobs are done and the non-tap
workers are sitting idle, but the poor tap worker has a backlog.
This way the tap jobs for updates can be split across two
worker hosts, which should help out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's no need to run this twice (which can happen on some
paths), so if the first file already exists, just bail. Also,
don't bother uploading the config files any more - that was just
for debug while I was making this stuff work, now it works, and
this saves some time.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's one point in the tests where we may log into cockpit for
the second time in one run (it depends how a package update
process goes). When this happens, we don't get prompted again
for admin access, so we need to *not* expect that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems to time out a lot on lab but not on prod, for some
reason. Let's just give it a little longer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
From 280, the cockpit package disabled logging in as root by
default. We could wipe that config file, but it seems better to
respect the default config and log in as the admin user 'test'
instead of as root.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 3208d15725 and
the two follow-ups. I'm hoping
https://bugzilla.redhat.com/show_bug.cgi?id=2133829 is now
resolved; this was intended to help with that (though I'm not
sure it ever really did), and so we can hopefully ditch it, which
simplifies this code.
Hopefully https://bugzilla.redhat.com/show_bug.cgi?id=2133829
is fully resolved/worked around by now, and we shouldn't need
these any more. We could drop back to 2G but let's just do
3G for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Rawhide 'accept fate' text seems to have lost its Japanese
translation for some reason (I think the string might have had
a terminating period removed). And in one test, the "Extract"
menu item in Archiver was pre-highlighted so the needle didn't
match. Not sure why, but this doesn't seem like a problem, so
let's just handle it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was from F35 era when Cloud_Base worked on UEFI on Rawhide
but not F33 or F34. Now F34 is EOL, we can just follow the same
policy for every release (run two tests on both BIOS and UEFI,
the rest only on UEFI).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
