These actually *do* need it because they have START_AFTER_TEST
set, but they're still install tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
PXE install on UEFI (incl. aarch64) is failing at present, this
seems to be due to a grub bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2152763
we're really intending to test the client side here, not the
server end, so let's work around this problem on the server end
by installing a grub2 scratch build that's the package from just
before the bad change, but with the release and epoch bumped,
from a side repo.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should always be safe (in the four cases where it's set,
the previous test will have set up the advisory repo), and saves
us a reboot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is safer if the advisory stuff was done on a previous test
run. Hilariously, this exposed a dumb mistake I made years ago
in installedtest.pm and never noticed before: the calls to
advisory_* at the bottom of that file are meant to be in the
post_fail_hook, but they weren't, which meant they got called
by the scheduler. This didn't cause any failures because the
first line caused them to return immediately based on a get_var
call (which it's OK to do in the scheduler), but changing it
to a script_run call (which it's *not* OK to do in scheduling)
caused all the tests to blow up immediately and confused me
*a lot* until I spotted this!
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This turns out to be overcomplicated. We don't need the special
handling for updates any more, because a few months after we
implemented it, we had to make sure the affected update tests had
an empty START_AFTER_TEST anyway, or else openQA would refuse to
schedule them. So we can just rely on the START_AFTER_TEST
condition for those now. We also don't need the additional
INSTALL_NO_USER condition; the only case where it's actually used
is for install_arm_image_deployment_upload on Workstation, and
that test does not have START_AFTER_TEST set, so the other
condition catches it for welcome screen handling purposes. There
is no need to nest the IMAGE_DEPLOY conditional inside a check
for the desktop and the INSTALL_NO_USER var either; we don't
test any other desktop on ARM, and the IMAGE_DEPLOY var is only
set for that one install_arm_image_deployment_upload test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We recently started using the buildroot repo for Rawhide update
tests, but weren't including it in the image build tests. This
should include it in all the image build tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When I enabled _advisory_post for live and ostree install tests,
the point was to check that updated packages were included in
the install media and used during installation. We shouldn't run
a system update in _repo_setup_updates on this path because it
will hide the problem if the updated packages weren't included.
The INSTALL variable is for this purpose - it was previously
used to skip _advisory_post on the same path. At the same time
let's remove some stray settings of this var on non-update tests
as it serves no purpose there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per discussion at https://pagure.io/fedora-ci/general/issue/376
it really feels like this is the right thing to do. There are no
buildroot overrides for Rawhide, so we don't have to worry about
cross-pollution. The buildroot repo only contains builds that
have been tagged stable since the most recent Rawhide compose,
and thus will go into the next one. It makes sense to test later
updates against these. This avoids issues like:
https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=38&build=Update-FEDORA-2022-30a952e331&groupid=2
where the tests of an update failed because it requires another
update which had been submitted and tagged stable previously, but
after the last compose.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We currently snapshot after every run of _console_wait_login or
_graphical_wait_login, which means we snapshot *twice* on most
update tests as those modules get run twice. However, we almost
never use those snapshots. Snapshotting takes quite some time,
and hits the disk pretty hard, so we should avoid it unless it
is really needed.
We only have a few modules that are not fatal (and so might use
the snapshots), and most of those don't run after one of these
tests, or run after a later module that's also a milestone. Best
I can tell, only two test suites really need to use a snapshot
from a login test: server_cockpit_updates and modularity_tests.
To handle these and potential future cases, we'll add a new
module that does nothing, but is marked 'milestone', so it will
take a snapshot, and load that test after the login test if the
var LOGIN_SNAPSHOT is set, and set that var for those two suites.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
it's really just a dupe of the -problems needles, it turns out,
Lukas was reinventing that wheel. He had to add another one
today because I broke the JSON in this one when I was simplifying
it yesterday, but I think this one on the new -problems needle
are really just dupes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We started using this in real composes a year or two back, so
openQA should do the same. It drops the nesting of an ext4 fs
image inside a squashfs image, just using a single squashfs
image instead. This results in smaller images - missing this
is why the images built by openQA were coming out larger than
the real ones.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
* Scarborough provided quite a messy map that resulted
in frequent needle failure. Changing the location
for something better to make it more reliable.
* The zoom test could have failed with a low resolution
image. Adding some timeout to the needle give more
time to load the proper image.
The check_screen function checks for the existing tag
but it only waits 1 second by default. In this time,
Abrt will not even start so we need to prolong
the check_screen timeout to make sure the application
has started (or at least give it enough time to try).
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>
