It seems like 480 is a bit low for our oldest, slowest x86_64
worker hosts on the lab instance (worker03 and worker05), they
frequently hit this and fail. Let's bump it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Fedora Rawhide (to be 43) has new applications that replace
the older ones, namely Papers replacing Evince and Showtime
replacing the Totem.
We are adding a condition to run correct applications on Rawhide
while retaining the older applications for a while until the change
has been made in whole.
Fixes: https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/375
This seems to be sometimes *causing* problems now. In some cases,
the first launch actually worked but we don't wait long enough
for anaconda to show up, so we launch it twice, and that can
cause failures like https://bugzilla.redhat.com/2360859 .
I did a dry run for a few days on staging and just dropping the
loop entirely didn't seem to produce any failures-to-launch, so
maybe the various bugs we added this for in the first place have
all gone away? Let's try dropping it. If we run into failure-to
-launch problems again, we can add it back but bump the timeout
or something.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In two cases we don't need separate needles for identifying a
screen and then clicking something on it: we can just also use
the thing-to-click for identification purposes. Also remove the
connect_button-verify needle which has never matched (it matches
on the Verify button but has the tag for the Connect button, no
idea why), and update all the needles for the new GNOME fonts.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Oh, no particular reason or anything. *ahem*
https://bugzilla.redhat.com/2358785
This should cover a decent range of transient bootable media,
ensuring the UEFI fallback mechanism doesn't kick in if you're
just booting the installer or live environment.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Today it has a much more KDE-y window appearance, without bold
titles. Not sure why it's different from yesterday, but never
mind.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's now a header bar in fullscreen mode which appears until
you move the mouse away from it, and screws up the needle match.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sometimes the clock is at 14:38 not 14:37 when we hit this point
in the test, so we need two needles. The 14:38 one hadn't been
updated for the new font yet.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This got messed up in 1e6da7019c
where the KDE needles all got renamed to apps_run_abrt* and their
tags changed to apps_run_abrt, but the KDE *test* was not changed
to look for apps_run_abrt instead of abrt_runs, so we wound up
creating a whole new bunch of abrt_runs needles so we had *three*
sets of needles...
This rationalizes it down to the needles that actually match in
current tests, properly renames them all to apps_run_abrt and
updates the KDE test to look for that tag, and adds a couple of
new needles for the recent downgrade of the app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The image changes size a bit depending on changes to the text,
I think that's why we always need a variant of this at release
time.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think it should be OK to do this without any fancy conditions.
It'll fail for F41 respins, but eh. May fail for F42 nightlies
until we push the update stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Trying to fix the frequent failures of this test, still. I don't
think we need the loop if we make sure to select the *parent*
entry in the list, which the needle tweaks should ensure, but
we might need to click twice to ensure it's selected and not
delete the entire btrfs volume by mistake, which is what we keep
doing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When there are critical updates available, the message differs.
This is the first time we've had critical updates since the
font change.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This caused problems (particularly with the more obscure package
install paths like cockpit and realmd) before, but I don't really
like removing it, as it differs from real-world usage. Tests are
currently failing because of a bug in this repo wiping - in
upgrade_preinstall, we should wipe the file again after the
dnf -y update --refresh call, in case that reinstalls it - but
instead of fixing that, let's try just leaving the file alone.
The risk here is that we run into problems when the repo doesn't
exist, again. In theory we should not because it has
skip_if_unavailable=True , and everything *should* respect that.
But if it does turn out to still be a problem we'll have to
revert this and fix upgrade_preinstall.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We currently use script_run (not assert_script_run) for the
catch-all update we run at the start of the test, and don't use
--best. This means that if a dependency issue happens at this
point, we don't catch it yet, we only catch it in _advisory_post.
By using assert_script_run and --best, we can fail on dep issues
at this point. We have to keep the _advisory_post check to catch
dep issues that crop up *later* in the test, including when
things like Cockpit or GNOME Software install updates and we
can't force them to use --best logic. But we can at least catch
*most* of them earlier this way.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Because of the 'can't go from > 41 to <= 41' issue, we need to
tweak the coreos rebase targets to get the tests to pass.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think since the wayland port, sometimes clicks on
anaconda_blivet_part_drop_select are missed and don't open the
menu. So, if that happens, click it again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
it seems like sometimes we delete the entire btrfs volume instead
of the root device we're trying to delete; I think this is
because we click delete *immediately* after clicking the device,
and that might be too fast. Let's see if a wait_still_screen
helps. See:
https://openqa.fedoraproject.org/tests/3353598https://openqa.fedoraproject.org/tests/3299570
etc.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This came up in blocker bug meeting discussion today. We really
should check that all packages are signed after a default install.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This one is only needed if we don't see another log detail title
that we usually do see, so it escaped being updated for a while.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
