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.
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.
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>
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>
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>
This PR builds on some elements of the current upgrade process,
such as upgrade_boot, upgrade_preinstall, upgrade_postinstall, but
replaces the upgrade_run with graphical_upgrade_run to use graphical
methods to upgrade the system.
This would not be possible without necessary settings, that are
performed by graphical_upgrade_prerequisites.
Works for both Gnome and KDE.
This PR partly solves the issue #301 when it adds the navigation
testing for Gnome. It uses the keyboard combinations to cycle through
running applications and checks that applications could be switched
accordingly. It also tests that you can switch between workspaces
and that you can move an applications to another workspace.
Somehow these two got completely scrambled, testing the wrong
things on the wrong images. Fix them to match the non-blivet
counterparts, which are correct.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The silverblue tests are flaky because of
https://github.com/fedora-silverblue/issue-tracker/issues/548 .
The desktop_upgrade_encrypted test is flaky on Rawhide (so, when
booting from F40 initially) since we switched to UEFI, not sure
if it's because of UEFI somehow or just a timing coincidence.
Am going to look into it, but for now this should save lots of
manual restarting.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
ELN can't boot with Secure Boot enabled currently:
https://github.com/fedora-eln/eln/issues/183
Until that's resolved, let's go back to testing on BIOS (this is
easier than testing on non-SB UEFI for...reasons).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This essentially inverts the x86_64 machines so that '64bit' is
UEFI and instead of a variant 'uefi' machine we have a variant
'bios' machine that is BIOS. The point is to make UEFI testing
the default. We also enable Secure Boot in the UEFI testing,
and add a test of UEFI fallback booting on various products.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Anaconda has dropped the ability to interactively configure
additional repositories, so this test cannot work any more.
It's now possible only with inst.addrepo or a kickstart.
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>
It's defaulting to 10Gi, which definitely has caused *some*
issues (the flatpak test fails because there isn't enough disk
space). I'm hoping this will turn out to explain why SB tests
have been generally so unreliable lately.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per https://progress.opensuse.org/issues/151258 , PXEBOOT=once
doesn't work right in current os-autoinst. Now I look at it,
PXEBOOT is just pretty ropey in general; on UEFI and aarch64 it
doesn't actually do anything at all, we're actually just relying
on the default boot order there.
Since it doesn't seem like there's a practical way to make
PXEBOOT=once work as intended on all platforms, let's just drop
use of it and make it clear that we rely on the default boot
order: we hope that on first boot we'll get a PXE boot since no
local media are bootable, then on second boot we'll get a local
disk boot.
We set up a new IS_PXE variable to cue the couple of places where
the test logic needs to be different.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR tries to respond to issue #294.
On Silverblue, this will try:
* flatpak install
* flatpak remote-add
* flatpak list
* flatpak remotes
* flatpak remove
* flatpak update
and also it tests that a flatpak can be built.
It's super flaky ATM due to some GNOME/mesa bug(?) This will make
life easier till I have time to actually debug the issue.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Silverblue still has eog. It seems a bit excessive to bring back
the eog test just for Silverblue, so let's just disable loupe
until Silverblue has it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR adds a test for a new Image Viewer called Loupe.
It is based on the old Image Viewer test, newly reneedled
with some of the tests shortened, deleted or edited
as the new Image Viewer has a little bit less functions
compared to the previous one.
Add needles.
There's no obvious reason it'd ever give a different result on
KDE vs. Workstation, but since we added a matrix box for it on
both, we'd better run it on both.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The affected tests start after install_lvm_ext4, so we need to
bump HDDSIZEGB there, not in the downstream tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
With the 2G ESP change, we need bigger disks for these tests to
work correctly. On BIOS the test still just about works because
anaconda rounds the remaining space after BIOS boot partition
and /boot to 14G, but it seems fragile to rely on this. On UEFI
(aarch64), anaconda sees a max of 12G remaining after 2G ESP
and 1G /boot, so the test fails because we cannot size to 13G.
Give the test an extra 2G, this should be sufficient to make
sure it's valid on all platforms.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a Samba AD server test, and client enrolment tests via
sssd, Cockpit and kickstart. Requires the matching createhdds
commit to add the kickstart to the disk_ks image.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Modularity will be retired in Fedora 39 and the modular repository
removed. Also, the upcoming version of DNF that is default in
Rawhide, does not support modularity, so the tests are currently
failing anyway.
This requires a change in the package we use for base_update_cli
because pandoc-common is not in ELN.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The ISO or HDD image won't be attached to the post-upgrade
tests, and these are not tests of the image anyway, they're
tests of the compose.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As of yesterday's Rawhide, the modular repos are not installed by
default, so of course all the modular tests fail. So, install
the repos before running the tests.
This isn't conditionalized on release version as I don't think
we ever run this test on anything other than Rawhide and
Branched.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
desktop tests are very very fail-y on aarch64, with all kinds of
random failure cases. I suspect the worker hosts are just *slow*,
but they do have plenty of RAM per worker instance, so let's try
throwing a bit more RAM at each one and see if that helps at all.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The 'universal' flavor has been kinda pointless for some time
now. It dates back to the earliest days of openQA, before Pungi
4 was a thing, when composes were very different; we only built
a boot.iso and some live images nightly for Rawhide, these
weren't even formally grouped as a 'compose' at all (fedfind had
to invent the concept). The TCs/RCs had DVD installer images
(not *Server* DVD, at the time, just a universal DVD installer).
We wanted to run some tests on the DVD image if it was available,
but we still wanted to run them for the nightlies, so we invented
a whole mechanism for that - this 'universal' flavor, with some
complicated logic in fedora_openqa which schedules universal on
the 'best available' image it can find in the compose.
All this is functionally obsolete now. All composes we test are
now run through Pungi (except the live respins, but they aren't
relevant here). In current config, the Server DVD is non-failable
on x86_64 and aarch64, which means it will *always be there* -
if it fails to build, the compose itself fails, so we won't test
it. It's failable for ppc64le, but we don't care that much about
ppc64le; I'm fine with these tests just not running if the Server
DVD happens to fail in a ppc64le compose.
As a cherry on top, some of the 'universal' tests aren't really
universal anyway, they fail if you run them on a netinst (off
the top of my head, all the NFS install tests are like this, as
we use the ISO to populate the NFS share on the server end).
So let's just move all the tests that actually need an installer
image to the Server-dvd-iso flavor. Left over in the 'universal'
flavor are upgrade tests, which don't need an ISO at all - they
boot from hard disk images and run an upgrade using repos. We
can change the scheduler logic to be more simple for these, and
just always schedule them, with no ISO attached. We could even
rename this flavor 'upgrade', but it might not be worth it.
One slight complication is that the split happened to be helping
us avoid too many tests in a single support_server cluster; we
have a cluster of five support_server tests on Server-dvd-iso
and five support_server tests on universal. I try to avoid the
clusters getting too big as you need as many worker instances on
at least one worker host as your largest cluster; if you don't
have that many, the cluster's tests simply never get scheduled.
Requiring folks to have at least ten worker instances on one
host to run these tests is a bit of a big ask. So, to handle
that, we create a support_server_2 and have the former universal
tests use that one instead, so we'll have two separate clusters
on Server-dvd-iso now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We no longer build 32-bit ARM images and we hadn't had a working
setup for testing them for years anyway.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
