action #9492
closed
Test updates through Packagekit
Added by RBrownSUSE over 8 years ago.
Updated almost 8 years ago.
Description
right now zypper_up test is installing the updates. This needs to be disabled for desktop installations and instead we should test through packagekit applications, e.g. apper
- Checklist item changed from to [ ] SLE, [ ] TW, [ ] Leap
- Target version deleted (
154)
- Checklist item changed from [ ] SLE, [ ] TW, [ ] Leap to [x] SLE, [ ] TW, [ ] Leap
- % Done changed from 0 to 50
- Status changed from New to In Progress
- % Done changed from 50 to 80
can you enlighten us about the "weird issue" you noted in #9492#note-3 ?
My guess would be it's taking over 100 seconds for the update viewer to launch.. @mkravec does that make sense to you as a possible cause?
I think it's more the inverse, the updater opens up "too fast" while the "wait_idle" within the assert for desktop runner is still blocked and then the updater either closes itself or "esc" is forwarded to the wrong window?
Test is failing only on gnome@64bit-ipmi and jpupava told me today that ipmi does not understand assert_and_click. Might be connected to this?
Every backend has to properly implement every call of the testapi. Of course ipmi also knows assert_and_click. The problem is visible in the logfile and you are right that it is ipmi specific:
18:39:26.0265 Debug: /var/lib/openqa/share/tests/sle/tests/x11/updates_gnome.pm:26 called testapi::x11_start_program
18:39:26.0266 <<< type_string(string='gpk-update-viewer', max_interval=250)
…
18:39:27.2032 wait_idle sleeping for 15 seconds
18:39:42.2189 >>> wait_idle: timed out after 15
18:39:42.2194 <<< send_key(key='ret')
18:39:42.4215 <<< wait_idle(timeout=57)
18:39:42.4219 wait_idle sleeping for 57 seconds
18:40:39.4379 >>> wait_idle: timed out after 57
so the second wait_idle which comes from send_key 'ret', 1
is sleeping blindly for 57(!) seconds. During this time the update manager probably disappears because of a timeout again.
Why 57 seconds? The default for wait_idle is shorter but the ipmi-backend scales the timeout so we end up with these 57 seconds. Fix? Probably remove the "wait_idle", i.e. the ,1
from send_key
and replace with something proper.
Oliver, thanks - I saw 57s wait_idle, but did not think that gpk-update-viewer closes after 60 by itself :)
Also send_key confused me with parameter "1" not being seconds, but boolean..
PR on the way.
- Checklist item changed from to [x] TW
- Checklist item changed from to [x] Leap
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Also available in: Atom
PDF