Sigh, tests are failing on GNOME now - we're seeing the DBX
update even though we mask lvfs. Software must be catching it
before we mask lvfs or something. So let's wipe the plugin for
GNOME too. And use a somewhat more robust way of doing it, I
hope.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So I'm really remembering all the fwupd/lvfs issues now. When
there's a UEFI DBX update available, we'll see it. This can cause
different issues. Right now on KDE, we're trying to install it,
but LVFS is blocking the download because it thinks we're spamming
it. So that's making tests fail.
We really need to go back to just nerfing LVFS. I think I found a
way to do it on KDE that works with current Discover: just wipe
Discover's lvfs plugin entirely. This will break if the filename
changes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sigh. So we stopped masking fwupd becuase it caused Discover to
blow up, but now I remember why we started doing it in the first
place: fwupd can cause another 'type' of update to appear in
GNOME Software, with an identical "Restart & Update" button,
which openQA will happily click on instead of the one for
"System Updates" which we *want* it to click on. See
https://openqa.fedoraproject.org/tests/3880370#step/desktop_update_graphical/36
So...let's go back to masking fwupd, but only on GNOME. This
should make everyone happy.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 1a8f7e466c.
Current Plasma Discover complains if fwupd is masked. I just hope
tests don't start failing on fwupd errors again now. Sigh.
GNOME Software with the dnf5 backend prompts for GPG key import
if it hasn't already happened. We need to handle that. Luckily
I don't think we can get both this *and* the 'download unsigned'
needle, so we just make them alternates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When Software complains about something, it shows a grey banner
in the lower part with a button to click (Details).
The update test has not utilized this anyhow, so if it happened,
we would not know what the error was.
This fix makes sure to click on the Details button when it
appears, revealing the reason behind it, which could help
us understand what happened.
We have enhanced the menu_launch_type to allow for
start checking and maximizing applications.
This PR uses the new functions wherever it seems
logical.
If special logic was used for certain cases,
we have not touched these to preserve the
exact behaviour.
The crash workaround for the Fonts flatpak is dropped because it
no longer seems to be needed with the latest version of the
flatpak, and dropping it simplifies this migration.
Fixes: https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/358
Before this PR, we would have a different naming scheme
of application running needles for Gnome, a.k.a
apps_run_application, while for KDE we had application_runs.
This PR unifies all name under the Gnome scheme,
replaces the tags in the needles and test scripts.
This PR fixes https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/330
This is intended to address the problem that we don't use the
buildroot repo for Branched between branching and u-t activation,
which often causes problems when newly-created updates depend on
builds that recently went stable. So instead of having logic in
the tests that sets up the buildroot repo only if the release is
Rawhide (or ELN), we'll do the decision about whether to set it
up in the scheduler (which decides based on info from Bodhi), and
just have the 'set up the repo' steps in the tests. Let's also
use the same code and repo name for ELN and non-ELN so we don't
have pointless divergence there.
Depends on the matching fedora_openqa change, of course - without
that, no test will use the buildroot repo.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This isn't a test of fwupd, and we seem to be having issues with
it in openQA lately - I think maybe the fwupd server is blocking
openqa because we're hitting it too much? Anyway, let's disable
it for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now fwupd is showing us dbx updates, it seems we get *both* a
"Restart & Update..." button *and* a "Download" button at the
same time. If we click Restart & Update without clicking Download
first, package updates aren't applied.
So, tweak this logic yet again so that it 'breaks the tie' in
the way we want (if both buttons are present, click the download
one, take download out of the tags, and go to the next loop
iteration). Hopefully this solves the problem without breaking
any other paths.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The behavior after we click 'Restart to Install Updates Now'
button has changed in KDE 6.2. The default choice is no longer
'Install Updates and Restart' (even though that's what the button
says), and there is no timer. So if we don't click anything, the
confirm overlay just stays open forever.
This makes us click on the appropriate confirmation button if we
see it. We can also use this to make the test run a bit faster on
other releases, I guess.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In a couple of cases we type something that *doesn't* start with
a 'k', so we should use that other letter for the workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit b3e5dd41cb.
Some testing on lab seems to indicate it's not needed any more,
at least several runs with the workarounds reverted have passed.
Will put them back if we hit failures.
There's a couple of places where we do menu_launch_type in KDE
without doing this workaround first, and they do run into the
bug sometimes. Let's factor it out from the few places it's
already repeated, and add it to the places it is missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When using a side repo for testing a COPR or a side tag, there
may be unsigned packages. We set gpgcheck=0 to make dnf okay
with this, but gnome-software still shows a warning. Let's
click through it so the test can complete.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think the lack here is sometimes causing us to click more
times than we should. Let's do this to try and make sure we
don't click once it worked.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the same thing we do for the app_startstop tests in
aaa_setup, applied to a couple of other places we use
menu_launch_type in KDE and it's having trouble.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This whole complicated loop looks like it's no longer needed for
current KDE. It seems like we always refresh, then we hit
"Update All", and from there we go straight to "Restart Now".
Clicking the button always seems to work, we never seem to need
to click "Refresh" again. So, let's drop it and simply expect to
see and click Restart Now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In current F40 and Rawhide, this test is frequently failing
because gnome-software is behaving weirdly at startup - the
third-party software dialog moves around even more than before,
the app seems to get stuck in the "not responding" state
briefly sometimes, and there's a very weird state it gets into
sometimes where the window is shorter than usual and clicks
don't seem to register in the right place. While I'm trying to
bisect these bugs, these magic voodoo incantations (tested on
the staging instance) seem to mostly work around the weird
behaviour, and setting RETRY=2 should backstop it a bit further.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
GNOME Software seems to be doing some kind of animation between
the third party dialog and the main UI, and we're clicking on
a banner instead of the update button. Try a wait_still_screen
to deal with this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a new script - cleanup-needles.py - to use for cleaning
up old needles. It has to be used in conjunction with a database
query; the comment at the top explains how to do that query and
export the needed information. It produces a git commit with
needles that haven't matched since a certain date (specified in
the sql query) removed, subject to a 'keeplist' of needles we
keep even if they seem to be old.
I also enhanced check-needles.py to check for cases where tests
seem to be trying to match a tag we have no needles for. This
was necessary to find cases where the cleanup script was too
aggressive (i.e. the things that wound up in the 'keeplist'),
but it also turned out to find quite a lot of cases where the
code really *was* looking for a needle that had gone in a
previous cleanup or that never existed; the commits before this
one clean up a lot of those cases.
The code to decide which string literals are needle tags is
pretty dumb and hacky and needs some manual cueing sometimes -
that's what the `# testtag` changes in this commit are for.
Making it smarter would probably require this script to get a
lot more complicated and either incorporate or become a
tokenizer, which I don't really want to do.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now both GNOME and KDE do offline updates on all supported
releases, we never see an 'update done' screen any more. This
branch is left over from when the KDE offline update branch was
still conditional on release number.
If we ever implement this test on a desktop that doesn't do
offline updates, we can put this back easily enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Somehow, the dummy package being python3-kickstart causes the
graphical update tests (only) to fail for pykickstart updates
(that's the source package of python3-kickstart). The CLI and
Cockpit update tests are fine with this and pass.
To workaround this, use python3-blivet as the dummy package for
the graphical update tests when testing an update that contains
python3-kickstart. I've updated the test repo to contain both
dummy packages.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
If there are too many categories, we don't see the Updates entry
on the left, and this has been breaking Rawhide and F36 tests.
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>
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>
I've seen some failures caused by a sort of race where both
'apply' and 'refresh' needles match at the first assertion, but
openQA "prefers" the 'refresh' match. So we click the 'refresh'
button and *immediately* check_screen for apply, which is still
visible...but by the time we go to click it, it's gone because
the refresh found something new and now it's showing "Download".
This tweak should help, because if we can 'see' both refresh and
apply at the start, we'll just go ahead and click apply, we
won't refresh. The logic becomes a little more obscure, but I'm
not sure I see a fix for that. At least until KDE's tool finally
settles down for two releases in a row and we might be able to
simplify this whole thing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The 'desktop_pacakge_tool_update-kde-detected' needles and
'desktop_update_notification_systray-kde' needles are actually
matching on exactly the same thing, so drop the redundancy. We
need to have the desktop_package_tool_update tag on the older
(F33) version of this needle because on F33 we click on it to
launch the update tool in the desktop_update_graphical test; from
F34 onwards this is *not* what we want to do so the needle should
not have that tag to avoid throwing the test off. When F33 goes
EOL we can drop that tag from the needle and simplify the
destop_update_graphical test. Also add a needle for the Discover
app's 'update' icon when no updates are found.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Had some repeated failures where there's kind of a race between
Software doing some kind of auto-refresh and the test clicking
on stuff. This seems to help.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Man, this thing can get into a lot of states. Apparently somehow
it can go straight from refresh to reboot?
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE update was still often failing on #1943943, so this tries a
bit harder to work around it. We add a 'refresh' needle for KDE,
and tweak the 'retry' logic to click it if we get to that point.
Note adding the needle also changes behaviour slightly - we may
click this needle if we see it on first entering the screen. So
either change may be helping. Either way, this does make the test
more reliable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
