This also rolls in a few Arabic translations, I think, cos I
can't be bothered going through and picking them out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The rpmostree_rebase test has been failing on CoreOS 40+ for a
while. Per
https://github.com/coreos/fedora-coreos-tracker/issues/1672
it turns out this is because FCOS actually deploys OCI remotes
by default now. Rebasing from an OCI remote to an ostree
remote (as we are trying to do here) requires specifying the
registry, so let's do that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Creating the .invisible.txt file was done using non-assertion commands.
The tests have been failing for some and it seems like the commands
did not run correctly. Running them with assertions will make sure
that they will run (or fail correctly).
apps_menu_firefox and firefox/launcher are matching on the same
thing. Also, launcher-kde actually happens to match current
GNOME, so rename it to be generic. Give the launcher needles
the apps_menu_firefox tags and wipe the apps_menu_firefox
needle.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These loops make us click extremely fast. This may cause
unreliable results, I think. At least, the test is failing a
lot lately, with results that look like it's not always getting
the expected four levels of zoom. Let's try a short sleep
between clicks.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems like the export screen takes a while to appear on 40 and
Rawhide ATM, and we might start typing before it's there. Let's
assert it's actually there before we start doing stuff.
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>
In current F40 and Rawhide, this test is frequently failing
because gnome-software is behaving weirdly at startup - the
third-party software dialog moves around even more than before,
the app seems to get stuck in the "not responding" state
briefly sometimes, and there's a very weird state it gets into
sometimes where the window is shorter than usual and clicks
don't seem to register in the right place. While I'm trying to
bisect these bugs, these magic voodoo incantations (tested on
the staging instance) seem to mostly work around the weird
behaviour, and setting RETRY=2 should backstop it a bit further.
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>
Er, whoops, that was *not* meant to get rolled into an unrelated
commit and break every test on the public instance. Sorry.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The place where repos are defined changed on the F40+ branches
of workstation-ostree-config, this handles both possibilities.
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>
GNOME Software seems to be doing some kind of animation between
the third party dialog and the main UI, and we're clicking on
a banner instead of the update button. Try a wait_still_screen
to deal with this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It kinda looks like the text has been moved closer to the icon
in the latest gnome-software, such that the little '1' bubble
is now in the needle match area if it's present. Obviously that
may vary, so let's tweak the needle match area a bit to the
right so it's hopefully consistent and still matches on older
versions.
Another bunch of these timed out. Not sure why. Maybe it's when
I run a lot of them at the same time? Let's try this, again.
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>
