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>
This dialog gets cut off sometimes, it seems. That's a bug, but
we just want to handle it, because we want to quit cleanly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Man, this thing can get into a lot of states. Apparently somehow
it can go straight from refresh to reboot?
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE update was still often failing on #1943943, so this tries a
bit harder to work around it. We add a 'refresh' needle for KDE,
and tweak the 'retry' logic to click it if we get to that point.
Note adding the needle also changes behaviour slightly - we may
click this needle if we see it on first entering the screen. So
either change may be helping. Either way, this does make the test
more reliable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sometimes we click the button, it cycles briefly, and...just
comes back. To avoid unpredictable failures on update tests that
have nothing to do with the update, let's try and handle this by
just clicking it till it works.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Design team tweaked the new logo a bit in anaconda. We probably
won't need the old needle any more, but I'll take that out later.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Some apps moved around, others the needles stopped matching for
some reason, some kind of slight scale change or something.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The package with the new logo is not submitted as an update yet,
but we ran the tests on the Koji build and these are the new
needles. We'll need more when we run the full set of compose
tests on the change.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When we have to restart Cockpit during the update, we don't get
the usual "successful" screen after logging back in, we'll have
to match on something indicating an update did happen. I wanted
to use the little icon next to the package count but it seems to
have some kind of problem with anti-aliasing or something, I've
created two needles for it and neither matched on the next run
of the test. So let's match on this "reboot needed" text instead,
I hope it'll always be there when we hit this case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Make the 'deactivate overview if it's active' thing a bit more
robust by asserting the inactive state after deactivating it,
and add new needles for the new RC (text got a bit brighter).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Drop Firefox and NSS updates which have been stable for a while,
update the systemd one to the latest which should hopefully
finally workaround the DNS issues.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In GDM 40 the message is displayed only briefly, like in SDDM,
so we can't assert it. Only do it for <F34.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, extending the timeout didn't work. Try this instead. The
problem is when GNOME takes a long time to log out we wrongly
decide we're in the "DM is showing a 'screensaver' state" case
and hit 'ret' to clear it. In GDM that selects the highlighted
user. Maybe if we use 'esc', it'll still work in SDDM to clear
the screensaver state, but not select the first user in the list
in GDM...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a bandaid for GNOME taking a long time to log out right
now. I would prefer to make login_user more robust, but that's a
bit more complicated as it's used for both unlock and login.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit e23df39ee1,
putting the systemd workaround back in place, now we know how to
avoid the bug it causes. It's going stable tomorrow anyway, but
I want to re-run failed tests with the fix right away. Used the
update ID this time, not the build number.
This will avoid us hitting a crash in systemd during update when
systemd is being updated. That's a real bug and it's good that
it's been caught, but we don't want unrelated updates to fail on
this just because systemd is in the update set.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's causing crashes on update. I tried making us do an offline
update in repo_setup, not online, but that's actually quite hard
to implement so I'm not gonna do it on a Friday night. We'll
just live with unreliable _live_build for a bit longer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Main UI appears over the tip of the day now, so we can ignore it
and just check the UI ran then close it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>