Also be a bit more consistent about asserting we saw a terminal
and waiting a bit before typing stuff. We can drop the doublek
workarounds from the keyring tests as we no longer use the
kicker to launch the terminal on KDE (we use ctrl-alt-t shortcut).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This started out as just factoring out the repeated pattern for
launching a terminal on the desktop that came in with the i3
tests. But as I worked on desktop_login, which is a major user
of it, I noticed some potential cleanups and improvements in the
user switching stuff, and also realized we can turn that test
back on for KDE now - user switching was re-enabled in KDE a year
ago and is advertised to be reliable.
I don't think the "switch user from a lock screen" test fully
worked before, as we did not verify that we'd really switched
back to an existing session rather than starting a new one. Now
we do. Using the terminal to verify the logged-in user on all
desktops just keeps things simpler than using the kicker menu
on KDE (though if typing proves unreliable on KDE I may switch
this back).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Without this, all we did on i3 was hit alt-d and...do nothing,
we didn't type the app name.
I was confused at how we didn't notice this before, but it looks
like at present menu_launch_type isn't actually used in any
test we run on i3 (a lot of tests that use it to run a terminal
got a branch for i3 which uses alt-enter instead). This is an
obvious landmine, though, and it caused things to look weird
when rebasing #323 (which is how I noticed the bug).
This also refactors the sub to use the same logic for all
desktops, just with a different key for i3, since they really
all work the same. i3 doesn't need as much waiting as the other
desktops, probably, but it doesn't really hurt and keeps the code
simple.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The new NetworkManager update needs it. Lack of composes is
starting to bite us more, need to get one through.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Another update depends on it. It's gone stable already, but we
are having issues with composes ATM so it hasn't made a compose.
It's safe to do this as we can be sure the depended-on update
will be in the next stable compose whenever it completes, so we
can't wind up in an inconsistent state.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Over the time, we have changed the test scripts so that the code
in the i3.pm library was no more needed. The only leftover was the
user config subroutine that could be moved to the only file that was
using it and we could get rid of the library file.
There are several other tests doing the same thing (but not as
safely, in some cases). To improve reliability and reduce
duplication, let's factor this out into utils.pm and reuse it
where appropriate.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In a couple of cases we type something that *doesn't* start with
a 'k', so we should use that other letter for the workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should make the installer image build test work for ELN,
so we can try doing some update tests on ELN.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Changing to a conditional based on whether we saw webui broke the
ostree installer install tests, because they of course use the
same g-i-s even though they don't use webui. So, we have to go
back to the relnum-based conditional :/
Yes, this means we have redundant screens in g-i-s for install
paths that use gtkui to deploy GNOME, e.g. SB installer images,
but I can't see a good way to fix that. We need to show those
screens for the live install, which is the 'most important'
one, and we don't have an obvious way to show them for installs
that used webui but hide them for installs that used gtkui.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're dropping the live user mode patch from g-i-s downstream
because it's just too hard to maintain, apparently. So on Rawhide
the live image will boot to the welcome screen as normal, but
running the installer will give you newui rather than webui. If
you need a language other than English you have to sort it out
at the desktop before running the installer.
On first boot, g-i-s will show *all* screens, not skipping
language, keyboard layout or timezone, because we did not see
those in the installer.
This adapts the tests to handle the new flow, and should still
work with the other flows.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This comes with a subtle behavioural change that we no longer
pass --nogpgcheck for upgrade tests, but we didn't really *mean*
to do that for anything but Rawhide, and it *shouldn't* be
necessary for Rawhide now, so let's see if everything is fine
without it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In several places we run 'gnome-terminal' explicitly, but as of
today's compose, the default terminal app on GNOME in Rawhide is
ptyxis, not gnome-terminal.
Running 'terminal' should launch whichever is correct, so let's
consistently do that.
Also, add an apps_run_terminal needle and navigation navbar
needle for ptyxis.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As discussed in https://pagure.io/releng/failed-composes/issue/6538
we noticed a gap in openQA coverage here. We don't check the
versions of packages lorax installs to the installer environment,
and those packages do not make it to the installed system, so if
there's a dep issue that prevents a package in the update from
being included in the installer environment, but the same dep
issue isn't caught on any other path, we miss the problem. This
wires the updvercheck.py script into the _installer_build and
_ostree_build tests to catch this kind of problem, and makes it
capable of parsing pylorax.log files into its preferred format
to enable that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
To fix base_services_start always failing on aarch64, while I
wait for review of the upstream and downstream PRs.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
If the repo has source packages in it, we get a badly-formed
updatepkgs.txt that breaks updvercheck. So let's filter to only
packages of the target arch and noarch.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...when we're not in an atomic (canned) env, anyway. If we are,
we'll rely on it already being there (as previously ensured by
an earlier commit).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit a3f4a6f2e6. It
seemed to cause *more* annoying bars in Firefox than before, for
some reason, I don't know why. Reverting till I can do more
testing on lab.
SUSE has a much nicer style for handling all the nested quoting
and stuff in creating the autoconfig files, so switch to that,
and also merge in all the SUSE autoconfig values...the more the
merrier, for making Firefox be less annoying. I'm hoping this
might suppress the "Add a splash of color" modal that's breaking
tests ATM.
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>
Seems current dnf5 has a bug which causes repository refresh
progress to be sent to stdout even with -q.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...well, in this case, the Python side tag, because side tags
that inherit have just *all* the packages in them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
dnf5 behaves differently from dnf < 5 in a couple of ways: like
rpm it does not always add a newline to the query format, and it
sends its status messages to stdout, not stderr. These commands
account for this and produce identical output with dnf < 5 and
dnf 5.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
whoops, this bailout is too hard. we get here on tag/COPR path
if there are workarounds, that is fine.
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>
This broke the KDE app start/stop test. We need to click on the
desktop before alt-d-s will work, for some reason.
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>
From https://openqa.fedoraproject.org/tests/2594954 it looks
like this takes more than three minutes for updates with hundreds
of packages when running in a container (in the container build/
validate test). So, let's give it more time in that case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
