Drop the e2fsprogs scratch build workaround we were using for
https://github.com/fedora-silverblue/issue-tracker/issues/470 -
with the new 'use a custom ref and rebase to the official ref'
thing I implemented for update ostree tests, it shouldn't be
necessary any longer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This checks we actually deployed the 'fedora-openqa' ref as we
intended to (if not, the rebase test probably won't work
properly or won't test what we want it to).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We have had several problems where rebasing from one release to
another just doesn't work, and we have to work around it somehow.
Sometimes it's difficult or impossible to do. All we want to do
here is check the rebase mechanism itself; we don't actually want
to assert that you can rebase to any specific other release.
For update tests, we should be able to use a non-standard ref
name for the ostree we build, embed into the installer image,
and install. That should mean we can then rebase to the standard
ref name for the same release, which should be much safer than
trying to rebase to a different release. We can't do this for
the compose tests, but at least for update tests I'm hoping this
makes things more robust.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think this is new behaviour in rpm 4.19, or else we would have
run into this before when testing an s390utils update. But it's
easy enough to handle.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's not in the images any more. As aleasto pointed out, we're
actually being sent to Discover to install it, and matching on
*that* screen, which isn't what we intend.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per the upstream issue, this change was intentional (as a 'least
worst' option), so we shouldn't mark the needle as workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Add a link to the issue report for blivet-gui using an odd icon
for btrfs volumes, now I finally filed it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
F36 is now EOL, and from F37 onwards, grub is the bootloader in
any situation where it actually matters to do_bootloader (which
is only when we're editing parameters). We do still use syslinux
in the PXE tests on x86_64 BIOS, but we don't edit the parameters
in that case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
For a while, it seems like the test was often hitting a message
where the field we match on isn't actually visible because a lot
of other fields are shown first. So, add a variant needle that
matches on a different field, the message ID.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://github.com/storaged-project/udisks/issues/1102 - udisks2
seems to have a bug where it leaves filesystems mounted at a
"temporary" mount point after creating them. We need to work
around this when it happens or else we'll frequently get test
failures.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
util-linux-user subpackage was removed but comps wasn't updated.
I've fixed comps now, but that won't "kick in" until after the
next Rawhide compose; we need to workaround the issue until then.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These hit low-90% matches when run on the F38 respins for some
reason, just add another variant...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
If install errors out, currently we still wait like an hour for
an "install_done" screen that will never come, before we give
up. Since we have a needle for the "unknown error has occurred"
screen, we may as well use it here - if we see that screen, we
can just die immediately. This may go stale if we forget to
update the needle, but it's only one line, so meh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In https://openqa.fedoraproject.org/tests/1938847 , we wound up
doing an LVM thinp install when we meant to do a regular LVM
install, because LVM was already highlighted (for some reason)
in the scheme list, and the "LVM" needle is narrow enough that
it matched on the start of "LVM Thin Provisioning".
To avoid this, we make the match area in the existing needle
wider so it can't match on "LVM Thin Provisioning", and add an
alternate needle for LVM when it's highlighted.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I don't know exactly why this sometimes shows up highlighted and
sometimes unhighlighted, but hey, it's not wrong either way, so
we just handle it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
desktop tests are very very fail-y on aarch64, with all kinds of
random failure cases. I suspect the worker hosts are just *slow*,
but they do have plenty of RAM per worker instance, so let's try
throwing a bit more RAM at each one and see if that helps at all.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a new script - cleanup-needles.py - to use for cleaning
up old needles. It has to be used in conjunction with a database
query; the comment at the top explains how to do that query and
export the needed information. It produces a git commit with
needles that haven't matched since a certain date (specified in
the sql query) removed, subject to a 'keeplist' of needles we
keep even if they seem to be old.
I also enhanced check-needles.py to check for cases where tests
seem to be trying to match a tag we have no needles for. This
was necessary to find cases where the cleanup script was too
aggressive (i.e. the things that wound up in the 'keeplist'),
but it also turned out to find quite a lot of cases where the
code really *was* looking for a needle that had gone in a
previous cleanup or that never existed; the commits before this
one clean up a lot of those cases.
The code to decide which string literals are needle tags is
pretty dumb and hacky and needs some manual cueing sometimes -
that's what the `# testtag` changes in this commit are for.
Making it smarter would probably require this script to get a
lot more complicated and either incorporate or become a
tokenizer, which I don't really want to do.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We never hit this path without a system menu button any more,
due to changes in KDE over time. It hasn't been hit for two years.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now both GNOME and KDE do offline updates on all supported
releases, we never see an 'update done' screen any more. This
branch is left over from when the KDE offline update branch was
still conditional on release number.
If we ever implement this test on a desktop that doesn't do
offline updates, we can put this back easily enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's no need to do all this 'check whether it's selected and
click it if not' stuff (for three different mount points). Just
always click it. If it's already selected, clicking it again
doesn't hurt (one of these stanzas even clicks it *even if it's
selected*!)
If we need to cover both cases, we just need two needles with
the same tag, we don't need separate code paths. In each case,
though, we actually haven't matched one of the needles for ages
(the most recent was part_boot_selected, but now we're using
GPT by default, we won't hit that any more as it'll be the BIOS
boot partition that's selected by default), so delete the needles
we aren't matching any more. If we *do* hit any case where we
need to handle the 'other' state, we can just add the alternative
needle with the same tag.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This has not been hit for a year (on stg; three years on prod).
I *think* it would only be hit if we ran the test on an Everything
image, but as the test is now specifically associated with the
Server install DVD, that doesn't seem likely to happen.
If we somehow *do* hit ext4 pre-selected again, this can still
be handled simply by adding an alternate
anaconda_blivet_part_fs_ext4 needle which matches on ext4 already
being selected; that avoids the need to keep an alternate code
path around.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This branch is very fragile, because the test won't fail if we
miss the match on the security needle. So in practice, we are
never going to notice when the needle goes stale, and we'll just
wind up never triggering this branch and always going down the
other path. That's the current situation: the security_install
needle last matched more than a year ago at least. Let's just
admit the truth here and drop the branch entirely.
Also update the cockpit_updates_restart_ignore needle. This is
in a similar case - we don't really notice when it goes stale,
as the test completes, it just takes a bit longer - but since
this one is quite easy to find, let's just update it instead of
dropping it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was resolved upstream and we're no longer hitting this bug
in tests on F38, Rawhide or even F37 respins, so we should no
longer need this workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It looks like neither of these has been a problem for some time.
The notification needle has not matched for a year. The akonadi
needle doesn't exist any more - it was cleaned up in the 2021
needle cleanup, meaning it hadn't matched for weeks in 2021. I
checked the last several months of KDE app start/stop tests and
don't see any case where there was a stray notification that we
missed. So I think we can just ditch this whole mechanism for
now; if we have problems with these notifications again in future
we can put it back.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
