osbuild is struggling with the pre-release warnings ATM:
https://pagure.io/fedora-iot/issue/57https://github.com/osbuild/images/issues/515
Until that mess is cleaned up we can't really make sensible
assertions for osbuild images, so let's make the check a soft
failure for now (now we know about the bugs, we want to let
the rest of the tests run and not block them on this).
Note for IoT the behaviour has never really been correct (IoT
images never get pre-release warnings), but the logic in this
check matches the wrong behaviour (IoT composes always have
RC- labels even when they're clearly not RCs), so the test
didn't fail. While fixing this in osbuild we might try to get
'correct' behaviour for IoT, and then we'd need to tweak the
logic here.
While we're at it, tweak the implementation a bit; without this
tweak, implementing this 'soft fail if osbuild' behaviour is more
awkward and ugly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR partly solves the issue #301 when it adds the navigation
testing for Gnome. It uses the keyboard combinations to cycle through
running applications and checks that applications could be switched
accordingly. It also tests that you can switch between workspaces
and that you can move an applications to another workspace.
The worker containers aren’t using systemd-resolved so
get_host_dns() can’t find the dns server causing tests that need
it to fail. Add an alternative place to look for the dns server address
that doesn’t rely on systemd-resolved.
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
This is actually a very useful to wait a little bit before
we try to operate with the started application, especially
if we want to send keys.
Having this wait time here can save us doing this every time,
we start an application.
The mistypes on KDE are bugging me. Let's see if this - mainly
the wait_screen_change, the other just seems like a logical
tweak - helps at all.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
gvfs from the GNOME 46 megaupdate needs it. It's been pushed
stable but not included in a compose, yet.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's queued for stable but blocked by the freeze, and
FEDORA-2024-9c9174f3dd requires it. Let's just make it a
workaround to clear the other update's tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Just checking for the package update list is wrong in a couple of
ways:
1. It goes wrong for child tests that inherit the main disk from
the parent test, but not the second disk where the actual update
repo lives. They'll have the package list, but not the repo. So
we should test for both the package list and the repo dir.
2. It goes wrong for side tag tests, because we don't write a
package list (or create an update repo) on that path. So on that
path let's check whether we already created the repo definition
we use on that path.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=2268505 made it
clear that this is a bit of a hole. We don't test installing the
Silverblue image we build on UEFI, only on BIOS. Add this as a
separate test so we don't uselessly upload a disk image we won't
use for any follow-on tests.
This also adds an anaconda build that fixes a bug in this path
as a workaround for F40, so the test won't fail on all F40
updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should mean all F40 update tests get the new background,
and we can once again make that test fail if it doesn't see it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The Java 21 update broke FreeIPA and was waived stable. This
update rebuilds dogtag-pki and should fix it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I missed reverting the g-i-s page skip config when deferring
the webUI Change to F40. Now I changed the conditional in the
openQA test to expect F40 to behave like F39 and earlier, it's
failing because it's seeing too many pages. This should resolve
it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
jlebon and jmarrero figured out the fix for this, while we wait
for the packager to merge it their preferred way, let's use
scratch builds to work around it so every update doesn't get a
failed test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Another case where an update was submitted after its deps had
gone stable, but before they made a compose. Maybe we really need
to set up a buildroot repo for tests of updates to branched-before
-bodhi-activation too. I'll think about it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now the fedora-kickstarts PR to remove anaconda-webui was merged
we need this for tests to pass. Remove after next compose.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The new gnome-shell from FEDORA-2024-f543e8595c requires this.
We don't use a buildroot repo for Branched even in the short
period where it acts like Rawhide (no karma or time requirements)
so let's just use a workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
F38 is the oldest thing we test, and it has this flow. So let's
just drop the check here and always hit tab twice.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We should wipe it both before and after running repo_setup to
really get rid of it. Ideally we should stop doing this at all,
but for right now the repo isn't there for Rawhide post-F40
branching yet, so let's keep this until that's done.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't need this anaconda scratch build any more (the official
build has the fix now), but we *do* need the new lorax update I
just built to fix installer image builds with branched F40. See
https://github.com/weldr/lorax/pull/1379
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a scratch build with my proposed patch:
https://github.com/rhinstaller/anaconda/pull/5460
to get the tests to start passing again, so we don't have the
flood of red which makes it hard to spot other problems.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a surprisingly large change as we want to go back to
the console we were previously on after doing it. To do that we
need to know what console we were on, and to know *that*, we need
to port everything that currently uses (ctrl-)alt-fX to switch
consoles to use select_console instead.
This is primarily intended to make running setup_repos.py faster
when it has to download a lot of packages (as typing in hundreds
of package names is quite slow). But it actually makes the whole
thing faster, even when only downloading one or two packages.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This uses a Python script which implements concurrent downloads
(via asyncio) to download workaround and update packages and
configure the repos. This should speed up the process for large
multi-package updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
The issue is not marked as fixed, but per the needle cleanup we
have not hit this workaround condition for a long time. I checked
past failures and it doesn't look like we're still hitting the
problem but the needle stopped matching, or anything.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems the bug might just be that plymouth got more sensitive to
fast typing, so instead of waiting, let's try slow typing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
New Plymouth seems to have a bug where it shows the decryption
prompt briefly then shows a spinner and refreshes it, throwing
away any already-typed input. This is breaking our tests quite
often (any time os-autoinst is "lucky" enough to spot the first
brief appearance of the prompt and start typing). To work around
it, after we first see the prompt, wait for the screen to settle
and re-assert the needle before typing. This should reliably
wait out the refresh cycle.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
