The Rawhide 'accept fate' text seems to have lost its Japanese
translation for some reason (I think the string might have had
a terminating period removed). And in one test, the "Extract"
menu item in Archiver was pre-highlighted so the needle didn't
match. Not sure why, but this doesn't seem like a problem, so
let's just handle it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was from F35 era when Cloud_Base worked on UEFI on Rawhide
but not F33 or F34. Now F34 is EOL, we can just follow the same
policy for every release (run two tests on both BIOS and UEFI,
the rest only on UEFI).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts the last few commits which worked around a focus bug
in GTK. This bug is now (I hope) fixed, so I'm dropping the
workarounds so the tests will confirm whether it's fixed.
This is getting messy, but even the install_default_upload test
is failing out with 3G now. Let's try putting 4G here so it
reaches that test and see how that goes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is simpler if we just always lowercase $iso, plus it saves
us when somebody (*cough*) messes up the casing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In moving these from fedora_openqa to here, I got the casing
wrong, which breaks `tell_source` and causes a test to fail.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We had code in fedora_openqa schedule.py to set some params for
update tests depending on the flavor. I don't remember why I
ever wrote it that way, but that's an odd way to do it, the
obvious way to do it is just to have them here, like we already
have several others and like we do it for composes. This will
help with https://progress.opensuse.org/issues/119200 because
the params set by fedora_openqa schedule.py go in the request
URI but ones set here don't.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=2133829 is a real
problem for Rawhide KDE update tests right now, despite all
I've tried to do to work around it. I'm going to regenerate the
base image again tomorrow, but for now, let's bump RETRY to 2
as a mitigation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We keep running into 2119970 and it's really a pain restarting
tests manually all the time. So let's just retry the affected
tests three times. Big hammer time!
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We have a big problem with Rawhide KDE update tests getting OOM
killed during this phase. Stopping the desktop before we install
updates should save some RAM and help avoid this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think the reason the match failed is the pixels under the text
changed when the pre-release warning disappeared. We don't really
need a new needle, we just need to make the existing one less
tall so no part of the text underneath is included.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
mock 3.2 does not allow running as root. This breaks the live
image build tests. It's being reverted upstream, this scratch
build has the reversion backported.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Boy this seems slow in Rawhide currently. This has the effect
of being more defensive around the services page load.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We've seen some failures of the weather test at the start of
weather_report, where the test expects to be at the hourly view,
and instead it seems to be at a sort of broken state:
https://openqa.fedoraproject.org/tests/1505080#step/weather_report/3
I'm guessing this may be because currently aaa_setup clicks the
city name then is immediately complete, so it will immediately
snapshot. I guess this can result in things being stuck in a kind
of intermediate state on snapshot restore. So, to try and avoid
this, let's assert that we reach the hourly view after clicking
the city name, then wait_still_screen for a few seconds to make
sure things are settled down, before we complete and snapshot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Looking through more openQA failures I saw other desktop update
tests which were clearly caused by OOM kills, so let's give all
the desktop tests we run on updates 4G for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're seeing a lot of failures recently in desktop_browser caused
by the browser or desktop getting OOM killed. I've filed a bug
on this: https://bugzilla.redhat.com/show_bug.cgi?id=2133829
but we need to try and work around it, having the test failing
constantly is no good. Let's see if 4G of RAM is enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We see tests periodically come up incomplete with this:
"Migrate to file failed, it has been running for more than 240 seconds"
Turns out there's a setting for this, so...let's set it. I don't
think there's really a bug here, just when our workers are busy,
these migrations can take longer than expected.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We seem to be hitting very long loads on the Services and Logs
pages of Cockpit in recent Rawhide testing especially. As I don't
have time to deeply debug this at the moment, let's just give it
longer (but make it a soft failure when it takes longer than
expected).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
