[WIP] Assert desktop-runner is ready before sending 'ret' #5303
Conversation
|
I don't understand why we should need this, maybe you can explain in more details (in person is also ok) |
|
Investigating the unstable tests I realized that the 'ret' key was sent too early. While I agree that solving the force_cron_run first is better to remove those affected from the TO DO list, I haven't encounter any maintenance task running on the failed jobs in my last statistical investigation. Statistical investigation was: Verification with my changes: |
|
tricky. Of course you are right that force_cron_run and desktop_runner are impacting each other but desktop_runner should also be stable by itself. Currently I can not access your verification runs. I don't understand why you think https://openqa.opensuse.org/tests/697366#step/desktop_runner/1 is not enough to ensure that the desktop runner is ready or I don't understand your change, sorry :( |
|
In the link you show (https://openqa.opensuse.org/tests/697366#step/desktop_runner/1), desktop runner is ready to type on it, but not ready to press 'ret'. 'ret' is pressed before the program is shown on the list. |
|
Ah, I see. The problem is that I designed the desktop_runner test module in a way that it does not rely on the suggestions table to be computed because it can take so long and therefore make the test fail. So the idea was that we just call alt-f2, type something and abort. Your change is kind of trying the opposite. I don't know what to do better then right now. Maybe we can think of something better together … |
|
I consider #5409 a better alternative, please see if it is ok for you |
Avoid race condition by asserting that desktop-runner is ready before sending 'ret'.