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>
Upstream now sets an alarm with no explicit recurrence inactive
after it is stopped (previously it assumed recurrence every day).
We need the test to handle both behaviours for a while (until
we are no longer testing < 46.0 anywhere).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We now have some images using bootupd, at least Fedora IoT images
from F40 onwards do. These don't have a /etc/default/grub and
don't really intend you to run grub2-mkconfig. As advised at
https://github.com/ostreedev/ostree/pull/3150#issuecomment-1998768240
let's just add our required arguments directly in the BLS snippet
files.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We changed to building toolbox container images with Kiwi. These
are OCI archives, not docker archives. So we need to call skopeo
appropriately.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now we have F40 backgrounds, we can drop this exemption and have
the test always fail on non-Rawhide again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a workaround for
https://github.com/osbuild/images/issues/309 , the IoT installer
showing incomplete spokes in the main hub. We work around it by
visiting them all.
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>
We stopped doing this on Server because it caused problems with
tests that use a disk image uploaded by another test, e.g. the
cockpit tests - they use the `/etc/fstab` from the disk image
the parent test uploaded, which says to mount the second disk as
/mnt/update_repo, but since this is a new test it has a fresh,
empty second disk with no filesystems to mount. This tries to
fix that by making _console_shutdown.pm edit that line back out
of /etc/fstab, so we can set NUMDISKS=2 again (also on the ostree
flavor, which had a similar problem with the overlay and rebase
tests using a disk image uploaded by the install test).
We need to fix this because FEDORA-2024-9b9da603e1 is so big
it causes the tests that don't use a scratch disk to run out of
disk space.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This test is failing a lot recently on KDE because when we try
to launch konsole immediately after returning from a console to
the desktop, it is mistyped and we get a browser instead. Let's
try a little sleep after the switch back in case KDE just needs
to settle down a bit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On Silverblue, Fonts cannot be started using the menu_launch_type
for the first time, or it starts and crashes immediately.
However, if Fonts are started with flatpak run org.gnome.font-viewer,
it seems that the application starts and holds.
Let's start it using this workaround and when it still crashes, let's restart.
per https://pagure.io/fedora-qa/issue/766 , this is a hole in our
current test approach: we are testing whatever the current
'stable' toolbox image is for the release, not the image that
is produced as part of the compose. This enhances the test to
test both, when possible. If the var TOOLBOX_IMAGE is set, we
will first check that a 'normal' `toolbox create` works - i.e.
that all the toolbox logic works right and it can actually find
a default image to download - but then we throw that toolbox
away, download the image (the value of the var is expected to
be a URL for the image file), register it with skopeo, and then
recreate the container using that image. Then we proceed with
the rest of the test as usual.
If TOOLBOX_IMAGE is not set, the test should proceed as before,
using the 'default' downloaded image.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need to special-case the g-i-s update to get it stable before
we can actually change this in the real kickstarts repo...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
these were duplicates. In GNOME 46-beta this dialog seems to be
in 'light mode' at least some of the time, so we'll keep the
'light mode' gnome_allow needle we added for Snapshot but
rename it and change its tags. We'll wipe the 'dark mode'
gnome_allow because it should be just the same as the existing
grant_access needle. The two tests that used gnome_allow are
changed to use grant_access.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The rpmostree_rebase test has been failing on CoreOS 40+ for a
while. Per
https://github.com/coreos/fedora-coreos-tracker/issues/1672
it turns out this is because FCOS actually deploys OCI remotes
by default now. Rebasing from an OCI remote to an ostree
remote (as we are trying to do here) requires specifying the
registry, so let's do that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Creating the .invisible.txt file was done using non-assertion commands.
The tests have been failing for some and it seems like the commands
did not run correctly. Running them with assertions will make sure
that they will run (or fail correctly).
These loops make us click extremely fast. This may cause
unreliable results, I think. At least, the test is failing a
lot lately, with results that look like it's not always getting
the expected four levels of zoom. Let's try a short sleep
between clicks.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems like the export screen takes a while to appear on 40 and
Rawhide ATM, and we might start typing before it's there. Let's
assert it's actually there before we start doing stuff.
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>
The place where repos are defined changed on the F40+ branches
of workstation-ostree-config, this handles both possibilities.
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>
Another bunch of these timed out. Not sure why. Maybe it's when
I run a lot of them at the same time? Let's try this, again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
accounts.fp.o seems to be unreliable again today, let's drop this
again so tests don't fail on it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 56c9e80f60.
Things seem to have settled down with the mass rebuild and this
test seems to be back to consistently taking about 90 minutes.
It seems to be timing out a lot on Rawhide lately. Not sure if
it's just mass rebuild stuff, but anyhow...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit ab5b1a4367. A
new colord build has been pushed which should resolve the issue,
so I'm disabling the workaround to ensure that's the case.
Somehow, colord is sometimes failing to start in stable Rawhide
ATM - I don't know how this problem got through testing. It's
now blocking other updates.
Doing this only on x86_64 is lazy and wrong, but the logic gets
way more complicated if we need to allow potentially *two* things
to fail on aarch64 and ppc64le, and it's the weekend and we
don't gate updates on those arches so I'm not doing it. Hopefully
this will be resolved quite quickly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're taking a long time to reach it on aarch64 on prod recently
for some reason. It's probably some weirdness with qemu/edk2. So
let's just bump the timeout as I don't have an easy fix on hand
and this won't hurt anything.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We seem to be getting quite a lot of failures in update tests
where this times out. Let's try a longer timeout.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a surprisingly large change as we want to go back to
the console we were previously on after doing it. To do that we
need to know what console we were on, and to know *that*, we need
to port everything that currently uses (ctrl-)alt-fX to switch
consoles to use select_console instead.
This is primarily intended to make running setup_repos.py faster
when it has to download a lot of packages (as typing in hundreds
of package names is quite slow). But it actually makes the whole
thing faster, even when only downloading one or two packages.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This uses a Python script which implements concurrent downloads
(via asyncio) to download workaround and update packages and
configure the repos. This should speed up the process for large
multi-package updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This test had special flags because it used to be run first and
did the prep steps for the other tests. Now the aaa_setup test
does that job, so there's no reason for this test to have these
flags any more, and somehow they seem to be breaking the test on
Rawhide. Let's give it the same flag as all the other normal
tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per the needle cleanup, it hasn't been seen for some time. The
test is failing ATM but even the last time it passed -
https://openqa.fedoraproject.org/tests/2311371#step/kontakt/3 -
we did not see this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The bug this was meant to fix hasn't happened for months. Back
in Fedora-Rawhide-20230629.n.0 we were seeing every line in the
poem marked as a spelling error until we did this, but that's
not happening any more, we don't need this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This breaks things until a compose has happened and comps data
with the new group in it is actually out there in the repos. So
we need to hack it back out again till a compose goes through.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In some tests on staging this seems to help with the 'clicks
don't work in later test steps' problem we're seeing a lot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems Python 3.12.1 changed unittests' behaviour so that all
tests being skipped is now a fail not a pass. That breaks this
test because TestAtomic01Status only does anything if this is
an atomic system. So, let's just skip that test entirely if we
aren't one. As things stand this means the test will never run,
because we only test on Cloud_Base which is not atomic.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There used to be a theme.conf.user file, there isn't any more.
I think this should work both before and after.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
os-autoinst is set so that if you once manually set the cursor
somewhere, all subsequent calls to `assert_and_click` will return
the cursor to the last manually-set position (if you never set
the cursor anywhere manually, it uses the `mouse_hide` location).
The mouse_hide location is no good for modern desktops as they
use hot corners in various ways, so for the desktop tests, early
in login, we set the mouse to 300/800, which we hope is a kind
of neutral location that doesn't interfere with matches of the
desktop_background needles (which I usually put towards the
right of the screen).
Unfortunately, KDE can show fairly big previews of active windows
down there, and hovering over one causes that window to be
displayed and all others to be hidden. Which rather breaks the
desktop browser test, when we have the Welcome Center popping up
on boot.
We already moved the mouse set point from 300/200 a few years
back because of a *different* awkward interaction with the browser
test, so we can't go back there. Let's try 1023/384 instead -
that's all the way on the right hand side of the screen, but half
way down, not in either corner. I really hope this doesn't cause
problems for any tests cos I don't know where else to stick the
damn thing if this doesn't work.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Several needle updates and a tweak to the text we type to launch
kinfocenter (just "info" now launches something else).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
khotkeys was removed from Plasma 6, and qdbusviewer was only on
the live image because khotkeys recommended it, so now it's gone.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
tab will both reach the environment selection list and then go
through it, so we don't need to start out with tab and then
switch to down. And since all we need to do is hit one key until
a needle matches, let's use the handy function os-autoinst
provides for doing this...
This should fix it on current Rawhide (where it only takes one
tab, or zero tabs - not sure which - to reach the list).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
You can see what these args are trying to do, but the function
does not currently work that way. I think running it without
args should get what the test wants. If Lukas wants to refine
download_testdata so you can specify the payload and where to
extract it, he can do that, then put this back...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The KDE welcome tour is getting in the way of the desktop login
test. Try getting rid of it after logging in.
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.
