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>
This adds both the Gnome and the KDE tests to test the
Desktop Keyring. After a discussion with the Brno team,
how this could be tested without the need to rely on
external servers to log into, we set up a local FTP server,
we will log into it and remember the credentials and verify
that the credentials will be stored in the keyring correctly.
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>
Seems current dnf5 has a bug which causes repository refresh
progress to be sent to stdout even with -q.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...well, in this case, the Python side tag, because side tags
that inherit have just *all* the packages in them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
dnf5 behaves differently from dnf < 5 in a couple of ways: like
rpm it does not always add a newline to the query format, and it
sends its status messages to stdout, not stderr. These commands
account for this and produce identical output with dnf < 5 and
dnf 5.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
whoops, this bailout is too hard. we get here on tag/COPR path
if there are workarounds, that is fine.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We already try twice, but that seems to be not enough for the
annoying #2280840, we're often seeing failures.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The service cockpit enables is different when it detects dnf5,
since cockpit 317. Let's just make this an F40/F41 boundary
thing, and add the cockpit 317 update as a workaround for F41
until it goes stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This broke the KDE app start/stop test. We need to click on the
desktop before alt-d-s will work, for some reason.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The previous way of doing this isn't really safe. It assumes we
will find at least one string literal on any line containing
send_key_until_needlematch, and strips the last one, on the basis
it must be the key to press. But if the key to press is an
unquoted variable, this will strip the tag instead. And if both
the key to press and the tag are unquoted variables, this will
strip the most recent string literal we put into the global list
from some *other* line!
So instead let's try to be a bit smarter about how we parse
send_key_until_needlematch lines - just stripping out everything
after the first comma after "send_key_until_needlematch" - and
drop the dangerous "pop the last item from the list" logic. This
way we should always only find the needle to match, if it's a
string literal, as for other directives. We should never reach
the key to press so we don't need to worry about taking it out.
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>
They use base disk images, and it's too fiddly to try and
arrange for the one the update test uses to be UEFI but the
other to be BIOS...let's just keep these on UEFI but kick up the
retry count :/
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 508635ed1c and
the fix-up follow-up, because this causes the test to have a
different scenario which screws up gating. Argh. I guess we're
stuck restarting it forever. Let's bump the retry number even
higher instead.
There is a weird and annoying kernel bug ATM which makes entering
encryption passphrases into plymouth's graphical interface often
fail on UEFI VMs. Using a BIOS VM seems to avoid this, and the
bug is not getting fixed, so let's switch all these tests to
BIOS to avoid this annoying bug causing failures all the time,
especially for update tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
ELN changed to some new font, which means it now needs all its
own needles for any installer screen that matches on text :(
Here they are.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Yelp changed something that makes it render fonts differently,
so we get to update every needle that matches text in Yelp.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're getting failures in the update network install tests today
which seem to be because we're using an image built with systemd
256 to install systemd 255. This is because systemd 256 has been
tagged but isn't in a compose yet, and we use the Rawhide tag
repo when building the installer image but we don't add it as an
additional repo for the install itself.
This is obviously a hole in the process, we should use the extra
repos, where appropriate, all the way through. So this makes us
use both the Rawhide tag repo (when doing a Rawhide install test)
and the workarounds repo (when there are workarounds) for network
install tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is intended to reduce the amount of traffic we generate to
flathub, particularly so we can run this test on updates as well
as composes. We have to set a proxy and trust an SSL cert.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Japanese one was hidden by the UEFI encryption passphrase
entry bug, and the weather one we only hit when the test runs
at an unusual time.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This works more or less like testing side tags. We also fix up
some flow problems with this path (that also affect the side tag
case), and enable the package checks on this path - it's not too
hard really, we just need to write the updatepkgs file when we
set up the repo, which we can do with dnf repoquery.
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>
When running these tests on updates we inherit the main disk
image from server_cockpit_default, which has the repo config,
but the actual repo data is on HDD_3 which is not inherited.
We need to re-download the updates here to ensure they're
available to the tests (the automatic update test installs the
dnf-automatic package, so it should pull it from the update repo
if it is part of the update being tested).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When testing the update that implements the dnf5 switchover, we
need to patch the kiwi config on the fly for dnf5.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
