Project

General

Profile

action #93453

openQA CI: Certain Selenium tests are failing

Added by tinita about 2 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Concrete Bugs
Target version:
Start date:
2021-06-03
Due date:
2021-06-18
% Done:

0%

Estimated time:
Difficulty:

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


Related issues

Related to openQA Project - action #68284: Selenium tests fail with "sendKeysToElement: Server returned error message" on CircleCIResolved2020-06-22

History

#1 Updated by tinita about 2 months ago

  • Related to action #68284: Selenium tests fail with "sendKeysToElement: Server returned error message" on CircleCI added

#2 Updated by tinita about 2 months ago

  • Description updated (diff)

#4 Updated by kraih about 2 months ago

Opened a PR with a workaround. https://github.com/os-autoinst/openQA/pull/3930

#5 Updated by openqa_review about 2 months ago

  • Due date set to 2021-06-18

Setting due date based on mean cycle time of SUSE QE Tools

#6 Updated by tinita about 2 months 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.

#7 Updated by kraih about 2 months ago

  • Assignee deleted (kraih)

Workaround has been applied.

#8 Updated by kraih about 2 months ago

  • Status changed from In Progress to Workable

#9 Updated by mkittler about 2 months ago

  • Assignee set to mkittler

I'll try to find a way to reproduce this.

#10 Updated by tinita about 2 months 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.

#11 Updated by mkittler about 2 months 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.

#12 Updated by mkittler about 1 month ago

  • Status changed from In Progress to Feedback

#13 Updated by mkittler about 1 month ago

  • Status changed from Feedback to Resolved

PR has been merged

Also available in: Atom PDF