This makes them diverge slightly from official ones, but...we
need it to run updvercheck.py, and doing that in a container is
a pain because we have to get the input files in. So, let's just
make sure it's in our ostrees.
It used to be in them anyway, but last night it stopped being in
Rawhide ones for some reason.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Intentionally or not, a recent anaconda change made it so the
"text mode sucks, use VNC instead?" question is no longer ever
shown - https://bugzilla.redhat.com/show_bug.cgi?id=2293672 .
So, we should handle the flow where we just go straight to the
hub. If they decide this was intentional and kill the question
for good we can drop the path that handles it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These filenames changed again:
https://pagure.io/workstation-ostree-config/pull-request/523
and I'm sick of dealing with it. Let's just fire away at *.yaml,
it should be safe. If we ever need to check a file we can add
a targeted upload_log temporarily.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
using podman run leaves containers and/or images lying around; if
the thing being tested is big enough, we can wind up with enough
that podman just stops working (I saw this while testing the
python 3.13 side tag). To avoid this, use podman run --rm, which
clears up the container/image after the command is run.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Tests running in cloud instances are failing because installing
rpm-ostree packages, particularly writing the OSTree commit, is often
taking longer than the timeout maximum of five minutes.
Stop these tests from needlessly failing by doubling the allowable
time for installing each package.
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
When we test major KDE version upgrades, we get a post-upgrade
version of the welcome center again after the upgrade, which we
don't really expect. This breaks the background test because the
welcome center is in the way of the background, it doesn't seem
to break any other update tests. So let's just handle it here.
Fortunately this version has an "OK" button we can click.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
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>
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>
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>
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>
The bug number is wrong and I can't find the right one, d'oh.
We could *probably* safely remove this right now but I'm not
100% sure, I think it should be fine when F38 is EOL.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit b203f41f55.
The bug has been worked around for some time with a downstream
patch. Dropping the extended timeout means we'll notice if the
workaround is dropped prematurely or stops working.
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>
This test, much like _live_build or _installer_build, builds a
container image in a way intended to be as similar as possible
to how official compose images are built. The purpose of the test
is to make sure updates do not break official container image
builds.
At the end of the test, we also check that the built container
is functional (at least, that we can run a 'hello world' command
in it). This can't really be rolled into podman.pm because that
test is more about testing podman itself, and it's just a one-
liner here anyway. We also run the 'if any packages from the
update are installed, are they the versions from the update?'
check inside the container, which required giving that check the
ability to 'wrap' the rpm commands to run inside a container.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
containers-common seems to have inadvertently introduced a hard
dependency on composefs, but not expressed it as a package dep.
While I'm trying to get that fixed, let's ensure the podman and
toolbox tests don't fail on it.
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 is obviously more prone to mistypes, but firewall-config
seems to be timing out if we take more than 25 seconds to type
the password, and we take juuust too long with type_very_safely,
even after tweaking the sleeps to shorter wait_still_screens
here. We could twiddle with those even more, but let's just go
with type_safely for now, if that turns out to be too unreliable
I'll change tack.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is failing quite consistently lately because we're typing
too fast, we need to wait a bit after the sudo su at least. Let's
be safer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This comes from trying to fix the annoying recurring problem with
mistypes in KDE which has been going on since at least December.
First, we add the attempt to kind of 'precache' the kicker menu
in aasetting.pm. Then, I thought, all this snapshot loading has
to be putting a lot of load on the workers. And when each subtest
passes, it shouldn't really be necessary - they all end with
quit_with_shortcut(), which verifies that the app exited and we
got back to a blank desktop, so successful subtests should not
usually interfere with each other. We probably only want to
rollback on *failed* subtests, which is in fact openQA's default
behavior. There only seems to be one case where a test changes the
system state such that later tests might be affected, so I kept
always_rollback just for that one. I've run this through three
cycles on GNOME and KDE and it looks good.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Various changes to the Tour text needed needle updates. The
final screen doesn't say "Have a nice day!" any more, so let's
rename that needle.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Since 46, the 1 minute button is a quickstart, it doesn't just
set the timer but starts it. So we can't always expect to have
to click the start button. Let's keep it working both ways for
now for respin testing, we can drop it once we're sure we're not
doing any testing on F39 any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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.
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>
Oops, all other actions pushes need to happen *before* the reboot
action push, or the logic breaks.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
My anaconda patch for ensuring we get an EFI boot manager entry
on installs using bootupd (currently only 'canned', i.e. Atomic,
installs - IoT and Atomic Desktops - are affected) was rejected
and dropped in the latest Rawhide build. It'll probably also be
lost in the next F40 build. So install tests of affected images
have started failing. This is a kinda awkward workaround: on
UEFI canned installs, we check whether it looks like there is no
"Fedora" efibootmgr entry, and if so, we delete the entry for the
optical drive, so hopefully we'll boot via fallback path from
the hard disk on reboot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Whoops, we can't just use a straight match_has_tag there as we
did another assert in the middle...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
