Project

General

Profile

Actions

action #108977

closed

test fails in select_patterns - Not all patterns given in the job settings were processed

Added by JRivrain over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
2022-03-25
Due date:
% Done:

0%

Estimated time:

Description

Observation

This happens sporadically, we should investigate on how to stabilize this.

openQA test in scenario sle-15-SP4-Online-s390x-minimal+base_yast@s390x-kvm-sle12 fails in
select_patterns

Test suite description

Select a minimal textmode installation by starting with the default and unselecting all patterns except for "base" and "minimal". Not to be confused with the new system role "minimal" introduced with SLE15.

Reproducible

Fails since (at least) Build 116.4 (current job)

Expected result

Last good: 113.1 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by JRivrain over 2 years ago

  • Tags set to qe-yast-refinement
  • Project changed from openQA Tests to qe-yam
  • Category deleted (Bugs in existing tests)
Actions #2

Updated by JERiveraMoya over 2 years ago

  • Target version set to Current
Actions #3

Updated by JERiveraMoya over 2 years ago

I did a quick try and might have helped partially (my try is not merged and as it is sporadic hard to say), but we need to investigate further, still happening in slower archs:

sub move_down {
    my $ret = wait_screen_change(sub {
            send_key 'down';
    }, 20);
Actions #4

Updated by JERiveraMoya over 2 years ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable
Actions #5

Updated by JRivrain over 2 years ago

  • Assignee set to JRivrain
Actions #6

Updated by JRivrain over 2 years ago

  • Status changed from Workable to In Progress
Actions #7

Updated by JRivrain over 2 years ago

I suspect it may have been caused by the network latencies we experimented at the moment of the issue, as it seemed to happen only on s390 which is using VNC on top of another VNC session.
I retriggered the job 10 times, if it happens again we can try to increase the timeout, otherwise consider it as outcome of issues described in https://progress.opensuse.org/issues/108845

Actions #8

Updated by JRivrain over 2 years ago

  • Status changed from In Progress to Closed

10 verifications passed, plus 3 build prior to it. most likely due to network issues described in https://progress.opensuse.org/issues/108845.

Actions #9

Updated by JRivrain over 2 years ago

  • Status changed from Closed to In Progress
Actions #10

Updated by JERiveraMoya over 2 years ago

  • Status changed from In Progress to Closed

It didn't happen in a long time, as you mentioned it was related with Network issues, it is old code and we have some tickets to replace it by something more straightforward. Let's close it for now and reopen if really need it. thanks for taking a look.

Actions

Also available in: Atom PDF