[Fix] attempt to stabilize the Logged Into OpenShift test

[jstourac]

Tests.Jupyterhub.Test.Logged Into OpenShift test sometimes fails with the following error:

TimeoutException: Message: script timeout
  (Session info: headless chrome=118.0.5993.70)
Stacktrace:
 # 0 0x55c8c7a8e463 <unknown>
 # 1 0x55c8c7693166 <unknown>
 # 2 0x55c8c770f477 <unknown>
 # 3 0x55c8c76f7d82 <unknown>
 # 4 0x55c8c770ea60 <unknown>
 # 5 0x55c8c76f7b43 <unknown>
 # 6 0x55c8c76cad71 <unknown>
 # 7 0x55c8c76cc262 <unknown>
 # 8 0x55c8c7a6550b <unknown>
 # 9 0x55c8c7a6843e <unknown>
 # 10 0x55c8c7a67f49 <unknown>
 # 11 0x55c8c7a688d5 <unknown>
 # 12 0x55c8c7a6e817 <unknown>
 # 13 0x55c8c7a68c25 <unknown>
 # 14 0x55c8c7a4373b <unknown>
 # 15 0x55c8c7a80428 <unknown>
 # 16 0x55c8c7a80608 <unknown>
 # 17 0x55c8c7a8da1f <unknown>
 # 18 0x7efc3cca4802 start_thread

When waiting on //*[@aria-label='Application launcher']/button to be enabled.

This commit is a desperade attempt to stabilize such failure since I wasn't able to reproduce this issue locally.

---

CI: rhods-ci-pr-test/2185

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %
378	0	0	378	100

[lugi0]

@jstourac I'm not convinced this change would help stabilize the test you're targeting from the title of the PR.
What I wanted to try was to add a Run Keyword And Continue On Failure/Run Keyword And Warn On Failure/Run Keyword And Ignore Failure here: https://github.com/red-hat-data-services/ods-ci/blob/master/ods_ci/tests/Tests/500__jupyterhub/test.robot#L24

Then we'd do a second check after this line: https://github.com/red-hat-data-services/ods-ci/blob/master/ods_ci/tests/Tests/500__jupyterhub/test.robot#L31; if we were successful in clicking the element and moving to the dashboard then nothing else should happen, otherwise we would do an explicit Fail to not lose the problem hidden/ignored on line 24.

Granted, this would mean that L24 might still fail on the webdriver itself, but at the very least we wouldn't have the noise in the test report - I've tried multiple times to investigate this specific problem and never found a "real" fix for it unfortunately.

[jstourac]

Thank you, Luca, for looking into it! Yeah, I'm also not convinced that this change will fix the test in question. But still this seemed to me that such wait is missing there before the eventual tour is skipped.

Regarding your proposal - okay, I agree with you that this will solve the noise in the test results. Even though, I don't like that much because it's moving the actual test into a different test 🙂 but I won't block it if it will work though.

Btw - when you say you tried to investigate this already few times - are you able to reproduce this locally on demand?

[lugi0]

But still this seemed to me that such wait is missing there before the eventual tour is skipped.

Fair enough, I don't think I've ever seen the tour skip keyword fail in any context but better safe than sorry!

Even though, I don't like that much because it's moving the actual test into a different test 🙂 but I won't block it if it will work though.

Yes, I'm not loving it as a solution either, but I haven't been able to come up with anything better atm

Btw - when you say you tried to investigate this already few times - are you able to reproduce this locally on demand?

Unfortunately not, I can only see it fail through Jenkins at random times, so I have no reproducer which contributes to the difficulty in squashing the bug once and for all