There's a race issue with just treating it as a next button: it's
not in the same place as a next button. Sometimes in the g-i-s
code we actually get ahead of ourselves and click early, which
isn't really a problem when the buttons are all in the same
place, but if we click "Start Setup" in the middle of transition
to the Privacy screen - as in
https://openqa.fedoraproject.org/tests/745034#step/_graphical_wait_login/4
- the click effectively gets lost. So let's make it its own tag
and have the initial assert look for it too. That way we won't
match on it again in the main loop over "@nexts".
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Using .local is apparently Bad Form because it's reserved for
mDNS. However there doesn't appear to be any particularly Good
Form for what to call a test domain you never want to exist
outside of a closed system, apparently. Sigh. Let's try this.
Includes a bump to disk_ks version because the kickstarts on
that image also need to have this change applied.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Otherwise we can immediately match 'fs is already selected'
for the *previously selected* fs before the UI updates and exit
without actually changing the fs of the intended partition.
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>
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>
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>
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>
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>
Kernel 5.8.8 broke the installer by changing return codes for
partition operations, these updates are listed as fixing it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The F32 FreeIPA update that changed the web UI has gone stable
now, so remove it. A pki-core update has just come out that fixes
F32 -> F33 FreeIPA server upgrade test: add this as a workaround
for F33 so that test stops failing on every update.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Previously we were relying on `rpm -q` always outputting the
right package last. We saw some test failures on recent kernel
updates, e.g. https://openqa.fedoraproject.org/tests/658768 ,
which indicate this isn't always the case; there the 'right'
package was second of three for kernel, third of three for
kernel-core and first of three for kernel-modules. So we need to
make it more robust. This uses an additional call:
`rpm -q $pkg --last | head -1` to find the most recent package,
if there are more than one; this should always be the right one,
I hope. Note we cannot just add `--last` to the `rpm -q --qf...`
call because the output when you do that is weird; you get the
output you'd get if you just called `rpm -q --last` first, and
*then* the query-formatted output afterwards (though with the
modified order as expected). There doesn't seem to be any way to
get only the latter.
I also tweaked the log uploading so we always upload the working
logs even when the test passes; it can't hurt anything and it is
sometimes useful to have them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should work even if the ifcfg plugin is not present (hi,
CoreOS) or 'predictable' (har) network names are on.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The FreeIPA UI change that the previous commit adapted to is in
4.8.9. That's stable for Rawhide and F33 already, but still in
testing for F32, and won't go to F31. So we need to make the
change conditional on release number, and we also add the update
to workarounds for F32 so we don't have to do something awkward
while we wait for it to go stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In g-i-s 3.37.91, the first screen has a 'Start Setup' button
rather than a 'Next' button. Easiest thing for us to do here is
just to add a new needle which has the 'next_button' tag even
though it's clearly not a 'Next' button, because then the code
still works :) So do that, but give the file a suggestive name
and explain the situation in a code comment.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's failing about one in six tries currently, with Bodhi 5.5 on
the server end: https://github.com/fedora-infra/bodhi/issues/4105
this should work around that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The ones that were in there are stable now, plus downloading them
is hitting a bug in Bodhi and breaking tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is to make the infra folks happy, apparently using 10.0.x.x
and 10.1.x.x is causing conflicts since our actual infra network
uses those ranges too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The annoying submenus in the overview app list now scroll right
not down :/ have to adapt this function for that. Had to move
get_release_number earlier because perl ordering.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
See https://pagure.io/background-logo-extension/issue/26 - in
current Rawhide, the search box in the overview is not active
when the overview is opened, so you can't just open the
overview and type, you have to click it first.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should avoid the bug happening in upgrade tests (I already
built the fix into the base disk image, which should avoid it
happening in other tests).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
See https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2878 .
GNOME 3.37.2 seems to have a bug with submenus in the app menu;
the first time you open one you can't scroll through it using
the keyboard. On every open after the first it works fine. This
is a quick and dirty workaround - when we're dealing with a
submenu, open it then close it then open it again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In Cockpit 220, the Updates entry is off the bottom of the screen
so we need to scroll the left bar down before we can click it.
Also update some other needles.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
