action #93453
closedopenQA CI: Certain Selenium tests are failing
Description
We are getting failures in the following tests now for every branch and PR:
- t/ui/01-list.t
- t/ui/10-tests_overview.t
- t/ui/12-needle-edit.t
- t/ui/15-comments.t
Sebastian is looking into it, and a bug in chromium or chromedriver seems likely.
The first failure showed up in the dependency PR: https://github.com/os-autoinst/openQA/pull/3929
But it also showed up in a PR from Ivan: https://app.circleci.com/pipelines/github/os-autoinst/openQA/6591/workflows/0a8a7bfa-a845-48f3-95e6-087beb7cb444/jobs/61998/steps
The artifacts/packages.txt is the same as in the last successful run:
https://app.circleci.com/pipelines/github/os-autoinst/openQA/6566/workflows/112ae53e-4d4b-4acd-9be1-3a67b435182d/jobs/61727/artifacts
Updated by tinita almost 3 years ago
- Related to action #68284: Selenium tests fail with "sendKeysToElement: Server returned error message" on CircleCI added
Updated by tinita almost 3 years ago
Created a bugzilla ticket: https://bugzilla.opensuse.org/show_bug.cgi?id=1186814
Updated by kraih almost 3 years ago
Opened a PR with a workaround. https://github.com/os-autoinst/openQA/pull/3930
Updated by openqa_review almost 3 years ago
- Due date set to 2021-06-18
Setting due date based on mean cycle time of SUSE QE Tools
Updated by tinita almost 3 years ago
- Priority changed from Normal to High
Increased the priority, as we can't use the workaround forever.
So far noone else has encountered or at least reported a bug with the new chromium version, so we need to find the cause or create a simple reproducer.
Updated by mkittler almost 3 years ago
- Assignee set to mkittler
I'll try to find a way to reproduce this.
Updated by tinita almost 3 years ago
Adding a note I wrote to Sebastian:
I think 01-list.t and 15-comments.t could be just a change of behaviour and not necessarily a bug.
10-tests_overview.t is weird because both Sebastian and I ran this without headless mode, and the inspector clearly shows that the value is like expected.
Updated by mkittler almost 3 years ago
- Status changed from Workable to In Progress
I've already been updating the ticket and I'm now also looking into the particular problems themselves.
So far I can tell that 01-list.t is definitely just a change of behavior. Before the API returned an empty string for an attribute value of an attribute which doesn't even exist and now it returns undef. (That's actually a change for the better as it allows to distinguish an absent attribute from one with an empty value.) I'll create a PR for adapting the tests. Of course the other cases might be different.
Updated by mkittler almost 3 years ago
- Status changed from In Progress to Feedback