1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-16 19:53:09 +00:00
Commit Graph

34 Commits

Author SHA1 Message Date
Adam Williamson
2226cea183 Update note as to why we use tty1 in desktop_notifications
It's been on 1 so long now I kinda don't want to change it to 3
or 4 or anything. That might break something. As long as it's not
causing any trouble let's just leave it on 1.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-13 12:45:20 -08:00
Adam Williamson
1a65993d36 Add a perltidy check and apply it to the entire codebase
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-28 14:38:38 -07:00
Adam Williamson
8c298851a4 Drop handling of 'transient' update notification in KDE
We seem to be solidly back to always getting a permanent update
notification in current F36/Rawhide, so we don't need this more
complex path any more. We also don't need these needles any more,
they haven't matched for months.
2022-05-16 15:53:22 -07:00
Adam Williamson
5d0309b147 desktop_notifications: give login screen a bit longer to appear
Seen a few failures where it takes just longer than 30 seconds
for GDM to show up here, e.g.
https://openqa.fedoraproject.org/tests/968142

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-09-03 16:56:17 -07:00
Adam Williamson
a35befab8c Workaround a notification test issue on F35 KDE
Closing the last notification in the tray closes the entire tray
now, which seems odd. Cope with that by re-opening it.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-09-02 11:10:16 -07:00
Adam Williamson
9d499eb5e1 Handle KDE having a permanent update notification again
Looks like the latest Rawhide got a permanent update notification
for KDE again. F34 is still around, though, so we can't just
revert to the old code, I don't think.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-06-15 13:56:00 -07:00
Adam Williamson
c7173ef0e2 Tweak KDE update notification handling again
On current F34 we get no permanent update notification in the
notifications view, we only get a *transient* one plus the
systray icon. This tweaks things so on F34 we check both of
those things correctly, behaviour on <F34 should be unchanged.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-02 17:23:53 -07:00
Adam Williamson
72369df2fc Set several extra schema keys for update notification test
GNOME got even more clever-clever about only checking for and
notifying about updates after a certain amount of time, so we
need to fake it out even harder. See
https://bugzilla.redhat.com/show_bug.cgi?id=1930401 and
https://wiki.gnome.org/Design/Apps/Software/Updates#Tentative_Design
Note the test will still fail for now as there is an actual bug
that needs fixing, but once the fix is in, this should work.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-03-05 17:56:56 -08:00
Adam Williamson
9392c66b45 Try hitting enter a few times at GNOME login screen if necessary
Another aarch64 robustness fix...sometimes hitting enter at GDM
just doesn't seem to work, let's give it three tries if needed.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-04 11:55:36 -08:00
Adam Williamson
3d8852cb60 desktop_notifications: wait longer at login screen
This matches the wait in boot_to_login_screen. The needle can
match before the UI is really done loading, and if we don't wait
long enough we wind up hitting enter before GDM is really ready
for us. This seems to be affecting the test on aarch64 quite
badly.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-04 11:55:36 -08:00
Adam Williamson
a008ffb8be Simplify desktop notification checks (#195)
This is the best option I can come up with to deal with #195.
Update notifications seem to have become transient in KDE lately
(even in F31 and F32, if I'm looking at these screenshots right).
This actually simplifies things a lot to do more or less the
same in the KDE and GNOME paths: open the 'permanent' store of
notifications (in GNOME you get to it by clicking on the clock,
in KDE via the systray) and then look for no notifications (live
path) or only an update notification (post-install path). We
only run this test for composes so we shouldn't need to worry
about anything older than F32, and I believe this should work
for KDE in F32 and F33. I left out click_unwanted_notifications
for now as I'm hoping it should be unnecessary, but we can add
it back in if necessary.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-14 23:30:00 -07:00
Adam Williamson
a0d4c2fc65 Add a keypress to the 'keepalive' loop in desktop_notifications
Just repositioning the mouse appears not to be enough to prevent
the sesssion going idle any more, since the 20200731.n.0 compose.
Not sure what causes this, probably the kernel. Adding a space
keypress seems to help in both KDE and GNOME.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-06 18:15:49 -07:00
Adam Williamson
ea9ac508ac Fix check_desktop variable timeouts
I forgot that tries was configurable. Sigh. Convert it to a
timeout argument.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-04-18 14:54:48 -07:00
Lukáš Růžička
f3d6a9574c Add desktop login test, revise and rename check_desktop
This adds a new test that implementsQA:Testcase_desktop_login
on both GNOME and KDE.

While working on this, we realized that the "desktop_clean"
needles were really "app menu" needles, and for KDE, this was
a duplication with the new "system menu" needles, because on KDE
the app menu and the system menu are the same. So I (Adam)
started to de-duplicate that, but also realized that "app menu
button" is a much more accurate name for these needles, so I was
renaming the old desktop_clean needles to app_menu_button. That
led me to the realization that "check_desktop_clean" is itself a
dumb name, because we don't (at least, any more, way back in the
mists of time we may have done) do anything to check that the
desktop is "clean" - we're really just asserting that we're at a
desktop *at all*. While thinking *that* through, I *also* realized
that the whole "open the overview and look for the app grid icon"
workaround it did is no longer necessary, because GNOME doesn't
use a translucent top bar any more. That went away in GNOME 3.32,
which is in Fedora 30, our oldest supported release.

So I threw that away, renamed the function "check_desktop",
cleaned up all the needle naming and tagging, and also added an
app menu needle for GNOME in Japanese because we were missing
one (the Japanese tests have been using the "app grid icon"
workaround the whole time).
2020-04-17 17:27:04 -07:00
Adam Williamson
252013fe3a Tweak desktop_notifications to work around #1821499 (again)
...this one should really work!

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-04-14 12:10:02 -07:00
Adam Williamson
0189b338d0 Drop all #1821499 workaround attempts
This stuff is kinda broken in various ways and halfline thinks
he can fix the underlying bug anyway. So let's go back to just
the GNOME live test being broken for now.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-04-07 15:14:57 -07:00
Adam Williamson
1c3106ebe3 OK, try setting GDM to debug mode instead?
I tested this workaround on staging before pushing it to git and
it worked, but then when I pushed it to prod it didn't work. On
stg I also had this to set GDM to debugging mode, so maybe this
is also needed for the workaround to work for some reason?

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-04-06 17:30:03 -07:00
Adam Williamson
b811d93c4c Try a sleep before hitting enter on GDM screen
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-04-06 17:19:06 -07:00
Adam Williamson
d8c7f85ecb Workaround RHBZ#1821499 in desktop live notifications test
A GNOME bug seems to result in us getting to GDM, not a liveuser
desktop, after running 'systemctl isolate graphical.target' from
a live boot to runlevel 3 since the end of March. This works
around that to let the test run, as it's not really a failure of
the test per se.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-04-06 17:05:11 -07:00
Adam Williamson
efec7010cb Handle an 'akonadi did something' notification in KDE, etc.
This handles a case where KDE shows a notification saying
'PIM Maintenance (Finished)', like this:

https://openqa.fedoraproject.org/tests/477345#step/desktop_notifications/34

we need to click it away for the desktop_notification test to
pass. It also clarifies the difference between this notification
and the eternal 'akonadi_migration_agent is doing something'
popup in the needle names and comments. It also replaces the
'check_screen then assert_and_click if found' pattern in several
notifications-related places with the better 'check_screen then
click_lastmatch if found' pattern now available upstream.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-10-30 09:05:06 -07:00
Adam Williamson
25f408ea7e Factor out clicking of update and akonadi notifications in KDE
There are three places where we basically want to click away
pop-up update notifications and the buggy akonadi_migration_agent
notification if it's there, in KDE tests. Let's share this code
between them, and also let's record soft failures for the buggy
cases in the desktop_notifications test.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-07-17 09:02:24 -07:00
Adam Williamson
43417f925c Whoops...actually decrease the counter
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-07-16 14:05:00 -07:00
Adam Williamson
34321dae8f desktop_notifications: handle multiple KDE update notifications
Current KDE seems to like showing us multiple update available
notifications. So the test must dismiss all of them. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1730482

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-07-16 13:58:15 -07:00
Adam Williamson
2e56facb68 Try to handle changes to KDE update notifications in Rawhide
The way KDE does update notifications has changed - it's now a
permanent pop-up notification. This is a bit awkward for our
logic; it's hard to define a needle that proves this pop-up is
the only notification. Instead, let's dismiss it, then open the
notification tray and assert that there aren't any others. But
we also retain the old behaviour (more or less) for testing old
releases.

The popup notification also blocks the 'refresh' needle in the
systray and so breaks the desktop update test, so we deal with
that too.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2019-05-30 17:34:09 -07:00
Adam Williamson
129d1316a6 Fix tty switching for desktop_notifications
Lately, we can't be sure the desktop will be on tty1 after we
do 'systemctl isolate graphical.target'. For recent Workstation
lives it actually shows up on tty2.

We could be 'clever' and switch to tty2 on F29+ Workstation
lives...but actually it seems like if we just don't do anything,
systemd switches us to the correct tty. So let's rely on that,
at least as long as it's working.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-10-12 21:16:33 -07:00
Adam Williamson
de3f4a873c Sleep a bit less in notification tests (to fix KDE postinst)
In F28 tests, the notification 'counter' thing that we rely on
to check there's only *one* notification seems to suddenly
disappear...right around 10 minutes after the desktop starts up,
which is just how long our test idles for to catch crashes that
happen a little after boot. That causes test fails. Let's try
just cutting the wait down to 8 minutes to see if that helps.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-03-28 19:20:29 -07:00
Adam Williamson
c2a5846064 Fix KDE live notification test (dismiss network notification)
KDE in F28+ seems to show a network connection notification on
live boot, for some reason. Just dismiss it to help the test
pass.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2018-03-28 19:01:46 -07:00
Adam Williamson
aca7de2861 Change up 'clean desktop' check again (use a util function)
Well, that OCR needle isn't working out so great, as it seems
to match when it shouldn't:

https://openqa.fedoraproject.org/tests/119217#step/_graphical_wait_login/5

So let's try another approach. Ditch the OCR needle and have a
function for checking we're at a clean desktop. It does the
normal needle match, but if we're on GNOME, it also tries
hitting alt+f1 and seeing if we're at the overview; if so, it
hits alt+f1 again (to go back to the desktop) and returns.
2017-07-10 11:47:07 -07:00
Adam Williamson
25b910135b Workaround cursor showing up on GDM in desktop_notifications 2017-06-06 18:16:52 -07:00
Adam Williamson
e68e113f76 Remove test_flags comments, add ignore_failure flag
It's not really a good idea to have the comments that explain
the test_flags in *every* test, because they can go stale and
then we either have to live with them being old or update them
all. Like, now. So let's just take 'em all out. There's always
a reference in the openQA and os-autoinst docs, and those get
updated faster.

More importantly, add the new `ignore_failure` flag to relevant
tests - all the tests that don't have the 'important' or
'fatal' flag at present. Upstream killed the 'important' flag
(making all tests 'important' by default), I got it replaced
with the 'ignore_failure' flag, we now need to explicitly mark
all modules we want the 'ignore_failure' behaviour for.
2017-04-10 15:00:10 -07:00
Adam Williamson
b67f604894 Move all remaining utility functions into exporter modules
Summary:
This adds a couple of new exporter modules, renames main_common
to utils (this is a better name: openSUSE's main_common is
functions used in main.pm, utils is what they call their module
full of miscellaneous commonly-used functions), and moves a
bunch of utility functions that were previously needlessly
implemented as instance methods in base classes into the
exporter modules. That means we can get rid of all the annoying
$self-> syntax for calling them.

We get rid of `fedorabase` entirely, as it's no longer useful
for anything. Other base classes keep the 'standard' methods
(like `post_fail_hook`) and methods which actually need to be
methods (like `root_console`, whose behaviour is different in
anacondatest and installedtest).

Test Plan:
Do a full test suite run and check everything lines
up. There should be no functional differences from before at all,
this is just a re-org.

Reviewers: jskladan, garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames

Reviewed By: garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames

Subscribers: tflink

Differential Revision: https://phab.qa.fedoraproject.org/D1080
2017-01-17 23:15:44 -08:00
Adam Williamson
7b31b8263e Force GNOME to notify updates, re-enable test on Workstation
Summary:
GNOME's update notification criteria are pretty braindead: it
fires the update check timer once on login then once every hour
thereafter, but only actually checks for and notifies of updates
once a day if it's after 6am(?!?!?!). So we have to do a bunch
of fiddling around to ensure we reliably get a notification.
Move the clock to 6am if it's earlier than that, and reset the
'last update check' timer to 48 hours ago, then log in to GNOME
after that.

Note: I thought this still wasn't fully reliable, but I've looked
into all the recent failures of either test on staging and
there's only one which was really 'no update notification came
up', and the logs clearly indicate PK did run an update check,
so I don't think that was a test bug (I think something went
wrong with the update check). The other failures are all 'GNOME
did something wacky', plus one case where the needle didn't quite
match because I think the match area is slightly too tall; I'll
fix that in a second.

Test Plan:
Run the tests on both KDE and GNOME and check they
work properly now (assuming nothing unrelated breaks, like KDE
crashing...)

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1039
2016-10-27 16:23:59 -07:00
Adam Williamson
fdeb333ff3 fix desktop_notifications to use assert_screen not check
whoops...this test should have been failing...
2016-09-30 09:21:01 -07:00
Adam Williamson
e9ce14a891 consolidate login waits, use postinstall not entrypoint for base
Summary:
I started out wanting to fix an issue I noticed today where
graphical upgrade tests were failing because they didn't wait
for the graphical login screen properly; the test was sitting
at the 'full Fedora logo' state of plymouth for a long time,
so the current boot_to_login_screen's wait_still_screen was
triggered by it and the function wound up failing on the
assert_screen, because it was still some time before the real
login screen appeared.

So I tweaked the boot_to_login_screen implementation to work
slightly differently (look for a login screen match, *then* -
if we're dealing with a graphical login - wait_still_screen
to defeat the 'old GPU buffer showing login screen' problem
and assert the login screen again). But while working on it,
I figured we really should consolidate all the various places
that handle the bootloader -> login, we were doing it quite
differently in all sorts of different places. And as part of
that, I converted the base tests to use POSTINSTALL (and thus
go through the shared _wait_login tests) instead of handling
boot themselves. As part of *that*, I tweaked main.pm to not
require all POSTINSTALL tests have the _postinstall suffix on
their names, as it really doesn't make sense, and renamed the
tests.

Test Plan: Run all tests, see if they work.

Reviewers: jskladan, garretraziel

Reviewed By: garretraziel

Subscribers: tflink

Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D1015
2016-09-27 11:48:15 -07:00