We can wind up with this a bit hidden by the bottom-left URL
location indicator, so shrink it a bit to hopefully match even
in that case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Otherwise we race between the needle match and the screen scroll
update, and can click the wrong thing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Cockpit update test relies on scrolling the Cockpit left bar
to find the Software Updates page, but in Firefox 100, the scroll
bars disappear shortly after the last time you moved the mouse.
To deal with this, instead of looking for a scroll bar to scroll,
we'll click the search box in the left bar and hit 'up' to scroll
it to the bottom.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Not sure what changed in the addon needles. For the webui needle
I think it's affected by the new scrollbar behaviour.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We get these variant needles with the keyboard icon and layout
name at slightly different relative vertical positions every
time we do a Final RC. I think the layout is affected by the
pre-release warning text no longer being present. Usually each
cycle something changes with the icon or with font rendering,
so the needles have to be updated, as in this case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When testing Rawhide updates we set VERSION to the Rawhide
release number, not "Rawhide". This post-upgrade version check
needs adjusting to handle that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seeing a failure quite often lately where when we try and hit
ctrl-p to print, we just type a p. There's no wait between
maximizing and trying to print, and only a short wait on
launch, so let's try being a bit more defensive there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So it turns out the translated layout indicators in Arabic are
intentional:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5257
so we can just add needles for them and we're good. Also update
a couple of other needles which need updates since we last
reached this far in the tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The new version of the F36 backgrounds means all these needles
that hit translucent panel elements need updating.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
SDDM looks slightly different on F36 since 20220319.n.0. The
Sleep / Restart / Shut Down / Other... buttons are visible, and
the keyboard layout indicator isn't. Previously on F36, and still
on Rawhide, those buttons aren't shown but the layout indicator
is. I'm not sure why this is, but it means the size of the name
labels is slightly different, and we need new needles.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This can actually take a bit of time, it seems, especially with
debug kernels. Let's give it a minute.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Lately anaconda can take up to 10 seconds to exit the root pw
spoke, which can defeat the subsequent `wait_still_screen` that's
meant to wait out the 'slide-in-from-the-top' animation of the
hub. So let's assert the hub after we click Done, then the still
screen wait will only happen *once the hub is visible* and should
really do its job.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We very rarely see this needle - only when we run the 'generic'
tests on an Everything image instead of a Server one, which
will usually only happen if we trigger it manually. I did this
recently to test an anaconda update, and found it needs an
update.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, this is annoying. GNOME Software intentionally does *not*
clear the 'download' or 'reboot and update' button when you hit
the refresh button, it just leaves them sitting there while the
refresh happens. So let's specifically require the 'refreshing'
text to appear and go away before we try and click on download
or apply.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Agh, GNOME's UI is *not* helpful here at all. The Apply button
remains visible for a long time after you hit Refresh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is yet another twiddle to that same damn bit where we try
to apply updates. This more or less reverts the last tweak to
it, where we skipped hitting 'refresh' if 'download' or 'apply'
are already visible. The trouble with that is that the app may
have already found and prepared updates before we got our
"prepared" python3-kickstart update in place - so the update
operation might work perfectly, but not update the package we
expect it to update, and the test may fail.
This time, let's try *always* refreshing, then wait a bit after
hitting the refresh button before we start looking for apply
or download to try and avoid the 'race' we were trying to solve
with the last tweak (where we hit refresh then immediately try
to hit a download or apply button which vanishes before we can
hit it). I think this should be safe as both KDE and GNOME
should always show a refresh button now (this wasn't the case
before, I think, F34).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a bug in the Save As... dialog on the flatpak version
of evince currently where the existing filename is not pre-
selected, so when the test types 'alternative', it gets
prepended to the existing filename instead of overwriting it,
and we wind up with alternativeevince.pdf, not alternative.pdf.
Let's treat this as a soft failure rather than a hard failure.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Again, a dialog changed a bit in the flatpak version of the app.
For this needle, the shade of grey is slightly different. Change
happened between Fedora-36-20220314.n.0 and 20220315.n.0.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The open/save dialogs for Flatpak apps in current F36 (and
probably Rawhide, but can't tell due to another bug) look a bit
odd: https://github.com/fedora-silverblue/issue-tracker/issues/245
This adds variant needles to handle various differences there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
For some reason various bits of gte started looking slightly
different on the F36 upgrade test. I don't really know why and
don't care enough to look it up. I'm just hoping all these
variations between gte running in slightly different contexts
calm down soon...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, so we can't have parallel tests on different machines, so
we can't have iot_zezere_server on 64bit and iot_zezere_ignition
on uefi. We need both to be on uefi. So, let's try using the
minimal-uefi image that we build for upgrade tests instead. It's
built for -1 (which is the same as CURRREL) on x86_64 and aarch64
so it should be there when we need it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It boots the 'support' disk image, not the image created by
install_default_upload, and that disk image is only set up for
BIOS boot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On upgraded systems, gedit might still be present; remove it so
we don't launch it by accident and try to test it instead.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I meant to include this in the earlier commit that does the same
for type_very_safely, but forgot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Both KDE and GNOME saw some changes to desktop_login needles in
recent Rawhide, this updates them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
