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>
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.
It seems like in current Rawhide (since about Saturday - possibly
due to new mesa?), g-t-e quite often dies after we print. This
messes up the test because we wind up quitting the terminal
instead of g-t-e. Let's handle it as a soft failure instead,
until we can figure out why g-t-e is dying.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
desktop_printing is failing a lot in recent Rawhide (and so are
some other tests, but this one is nice and easy to target). Add
some wait_still_screens and save_screenshots to try and see
exactly what's going on when we exit gnome-text-editor before
switching to a VT.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In today's Rawhide, two dialogs have to be cancelled on krfb
launch before we see the UI: a remote control permission screen
and a kwallet creation flow.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We often get a failure where it's stuck at a spinner here, let's
see if waiting to settle the snapshot resume helps.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It looks like
https://gitlab.gnome.org/GNOME/gnome-system-monitor/-/issues/262
won't be fixed for a while - the fixes are tied up with the GTK
4 port - so let's just work around it for now by clicking instead
of using keyboard shortcuts.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
A new app called snapshot (Camera, on the menus) has replaced
cheese in F40 (but not F39). Adjust to that. We can simplify
this when F39 is out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
If we do it after forcing the clock to 18:30, doing it takes so
long we wind up at 18:32, and that kinda sets the rest of the
test out of whack (we have several needles that assume we start
at 18:30 or 18:31 after the snapshot). So let's set the update
timestamp *before* we force the clock. This will mean it's waay
in the future after we force the clock, but that should still
do the job of avoiding notifications showing up, I hope.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE replaced Konversation (IRC client) with Neochat (Matrix
client) in Rawhide. As the replacement isn't done in F39 we can't
just switch the test out, we have to handle both, so for now,
let's have the "konversation" test run neochat on Rawhide.
We can't really proceed through neochat's first run wizard as
it needs a Matrix account name and password and we don't want
the hassle of handling a secret just for this, so we'll just
quit out once we see 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.
webUI has been deferred to F40, so we need to expect the old UI
flow on F39 now. This should cover everything, I hope.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're reverting webUI for Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-73c4f1a802
is the update that implements this; adapt the tests to handle it
(by expecting the old flow when testing that update, and editing
the kickstart to drop anaconda-webui when building the live
image).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This seems to have started failing periodically at the start of
this month, I've no idea why. For now, let's retry it a few
times and see if that helps.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There isn't any Help in the webUI installer, really. In future
it's meant to have more 'contextual' help - little question
mark icons next to elements of the UI that explain them when
clicked on - which we could implement tests for, but this isn't
done yet.
Let's not skip scheduling the test entirely, because we can
still run it on F38 respins, and we may be able to implement
testing of the contextual help in future. So let's just soft
fail and return immediately. If we get to F39 stable without
the contextual help being implemented (or it turns out not to
be testable within the confines of this design), we can skip
scheduling the test on webUI images entirely.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
