GNOME Software no longer has a welcome screen in any current
Fedora (it was dropped between 35 and 36), but in Rawhide it now
has a popup that prompts you to enable third-party repos which
we need to get rid of, so just convert the welcome screen check
to handle that, and drop all the welcome screen needles.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems ending the test right after we create the mutex can
cause the client not to catch it, sometimes. So let's sleep for
a few seconds after creating it to make sure it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These tests weren't doing it, I guess it's just an oversight;
this is probably why they often fail on slow repos.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This makes the two rpm-ostree tests written for IoT - overlaying
and rebasing - work across all rpm-ostree-based flavors we
currently test (IoT, CoreOS and Silverblue) and runs them on
all those flavors.
This requires some other changes. For the Workstation ostree
installer update tests, we have install_default_update_ostree
upload a disk image and run these tests on that image. That means
install_default_update_ostree cannot use a scratch disk (as if
we boot it with two disks but only upload one, the subsequent
tests fail to boot, looking for the missing second disk), but its
specified disk size should be large enough for all updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This test fails on Rawhide (because sddm-on-wayland) but we just
got an F37 respin, where it passes but needs some needle updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
All the deleted ones haven't been matched for five months. Drop
match level to 90 on the remaining ones, we got a 96 match for
one of them in today's respin test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I don't know why we wind up with so many slightly different
matches on the login screen. It's weird.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
What's supposed to happen here is the `do_bootloader` invocation
a few lines back boots to the installer, then here, we wait for
the install to complete and the system to reboot, and match the
bootloader again. However, on PXE installs, the bootloader screen
can hang around for quite a long time here, and if it does, we
can match it again before the installer starts up, and move on
too early. Hence the sleep.
It seems on current Rawhide 20 seconds isn't long enough - we're
still matching the installer bootloader after the sleep, see
e.g. https://openqa.stg.fedoraproject.org/tests/2431660#step/_boot_to_anaconda/3
This is causing the test to almost always fail (it'll only pass
if the install+reboot takes less than five minutes). Let's bump
it to 60 seconds and hope that's long enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Same conditions as used in main.pm to load the tests in the
normal flow. It makes no sense to do this on non-update tests,
or on the non-matching support server case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sadly, dropping this sleep caused the test to start failing
again at least on F36, so we still need it - update the note.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Thankfully this all calmed down a bit so we can simplify it a
lot. Clean things up a bit at the same time; escaping nested
single quotes is a lot clearer than concatening blocks with
different quote marks.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The bug seems to have gone away, at least I don't see that this
soft failure has been hit much for the last two months.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's been on 1 so long now I kinda don't want to change it to 3
or 4 or anything. That might break something. As long as it's not
causing any trouble let's just leave it on 1.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
