The g-i-s new user mode was removed in F34, so we don't need to
do this any more (as the now-removed comment said).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Before F34 we had to launch the update tool from the systray.
This isn't the case any more, so we can throw all this code and
these needles away.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We seem to be solidly back to always getting a permanent update
notification in current F36/Rawhide, so we don't need this more
complex path any more. We also don't need these needles any more,
they haven't matched for months.
Same difference as for English - 4 pixels of padding was added.
Also move a stray Russian needle to the right directory.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When we're logging via the serial console when a test fails and
no network is available, we only log the journal from the current
boot. But we might well need to see messages from previous boots.
So let's just log the whole journal.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Logging of additional repo setup changed recently in F37, we
need to handle the new message format here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2 seconds isn't enough to be sure it opened, which is causing
some weird failures in KDE Rawhide update tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
aarch64 tests are failing here because anaconda's still thinking
about the delete confirmation, it seems.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
