It seems like it can be *really* slow on aarch64, since 218:
https://github.com/cockpit-project/cockpit/issues/14840
this should give it a total of 180 seconds on aarch64 (90 second
still screen timeout plus 30 second assert_screen timeout, with
1.5x scale).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This sets us up to test the release-blocking aarch64 disk images
(Minimal, Server and Workstation). It also allows for testing
armhfp disk images on aarch64 worker hosts (though my testing of
that isn't going too well so far), and fixes the initial-setup
handling for a change upstream ('use password' is now the default
so we don't need to choose it). We rewire disk image deployment
test loading to work through the generic loader code rather than
using ENTRYPOINT, as it allows us to more gracefully handle
graphical (Workstation) vs. console (Server, Minimal), moving
the code for handling console initial-setup to a helper function
just like the code for gnome-initial-setup and having _console_
wait_login call it when appropriate. We also tweak desktop_vt a
bit because now we need to switch from a console running as test
to a desktop, which breaks the assumption that the highest
numbered session of user test is the desktop...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Rawhide KDE lives now have the desktop on tty2, and the installer
environment tty3 now has a shell (in Ye Olde Times it didn't, not
sure when that changed but it's the case at least back to F31).
So let's make our lives simple and just always use tty3 here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I noticed today that if we deploy FreeIPA with dnssec validation
enabled, dnf can't resolve dl.fedoraproject.org afterwards, which
is a problem because it means we wind up falling through to
random mirrors for metadata and package download once the server
is deployed, which can be slow and give old packages. This seems
to be why the server upgrade test on F33 is sometimes failing
because we get an older FreeIPA package on upgrade, even though
the newer one has been stable for a week.
It's difficult to pin down exactly where this bug is and fix it,
I've mailed some folks to try and work it out, but until that's
figured out, let's just disable dnssec validation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We've been getting failures lately on the first page load, I
think because Firefox is getting even more grindy on startup. So
turn the 'sleep' into a 'wait_still_screen', extend another wait,
and tweak the 'browser' needle so it only matches after the
bookmark bar has loaded rather than as soon as half the chrome
appears. Also make all the wait_still_screens use similarity 45
for consistency (flashing cursor could be there on any of them).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This check wasn't working, the test passed whatever wait_serial
found. This version suggested by defolos works, I checked.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Dropped the use of this in the recent notification simplification,
but forgot to remove the needle. Should've run tox...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the best option I can come up with to deal with #195.
Update notifications seem to have become transient in KDE lately
(even in F31 and F32, if I'm looking at these screenshots right).
This actually simplifies things a lot to do more or less the
same in the KDE and GNOME paths: open the 'permanent' store of
notifications (in GNOME you get to it by clicking on the clock,
in KDE via the systray) and then look for no notifications (live
path) or only an update notification (post-install path). We
only run this test for composes so we shouldn't need to worry
about anything older than F32, and I believe this should work
for KDE in F32 and F33. I left out click_unwanted_notifications
for now as I'm hoping it should be unnecessary, but we can add
it back in if necessary.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This does some of the things suggested by cheimes in
https://bugzilla.redhat.com/show_bug.cgi?id=1880628#c24 . It
seems to make the replica tests work with resolved, still work
with pre-F33 resolving, and not break anything. Also remove the
workaround to disable resolved if it's running, as we can now
work with it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't need a separate 'welcome' needle because it just matches
on an OK button anyway. So turn that needle into an OK needle
(we don't have any existing 'blue OK button' needle) and simplify
the logic to a single loop for kde_ok and krusader_settings_close.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
FreeIPA upgrade test is failing because of
https://bugzilla.redhat.com/show_bug.cgi?id=1886205. The test
failing every time is not useful as we know what the issue is,
so add the update as a workaround to avoid it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On ppc64le it looks like this test is often failing because it
takes a second or two to update the partition list after we
click update settings, but we're not waiting for that, so we
wind up clicking in the wrong place because we match the next
partition needle before the list is refreshed but click after
it's refreshed. Let's hope these waits solve it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It had krusader_settings_close as its tag, not kde_ok. That's
why the krusader test module was failing weirdly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Add FEDORA-2020-27f80050a2 as a workaround because without it the
KDE desktop background test fails due to the bug in -6.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We were using it to checkout a git version of python-fedora to
work around a bug, long ago, but we don't do that any more so
we don't need it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
openQA sometimes winds up testing an update that doesn't have
any packages for x86_64 (or aarch64). The most common case is
s390utils, which is on the critpath but only has packages for
s390x. I would ideally like to skip scheduling entirely if the
update has no packages for the arch we're scheduling on, but
sadly that involves using the Koji API which is XML-RPC and I
don't really want to deal with that again. This deals with it
at the test level instead, by checking the error message if
`koji download-build` fails and carrying on if it's the "no
packages for this arch" error. That means if the update has no
packages at all for our arch we're not really testing anything,
but that's better than a bunch of false failures, I guess.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Having systemd-resolved in use seems to cause problems for
FreeIPA servers:
https://bugzilla.redhat.com/show_bug.cgi?id=1880628
until the scripts are enhanced to do this or something, let's
disable it before server/replica deployment.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
ipa-replica-install already changes the DNS config to use the
local bind instance, we don't need to do this and it's actually
wrong (as it bypasses the local BIND we should use and uses
the VM host's DNS servers instead).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Kernel updates for F31 and F32 went stable so they can come out.
mock 2.6 fixes the bug that occurs when /etc/resolv.conf is a
dangling symlink - this breaks the live_build test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems what they had before worked until systemd-resolved became
the default; now we need to make sure we do nmcli mod and then
bring the connection down and up, as we do in tapnet.pm. Writing
to resolv.conf is kinda "wrong" for resolved but I don't think
it really breaks anything so I think I'll just leave those bits
in until F32 goes EOL just in case they're still somehow needed
on F31 or F32.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://openqa.fedoraproject.org/tests/667693#step/desktop_browser/8
shows us matching on Save File when the window is in kind of a
borked state; we'd probably wind up clicking on Open with,
because by the time we click the content of the window will have
moved to where it's actually supposed to be...so let's try this
to slow it down a bit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
