action #152542: Mismatch for needle with tag `yast2-security-ui` in module `yast2_gui/yast2_security.pm` - qe-yam - openSUSE Project Management Tool

Actions

Copy link

action #152542

closed

coordination #151816: [epic] Handle openQA fixes and job group setup

Mismatch for needle with tag `yast2-security-ui` in module `yast2_gui/yast2_security.pm`

Added by lmanfredi about 1 year ago. Updated 12 months ago.

Status:

Resolved

Priority:

Normal

Assignee:

JRivrain

Target version:

Start date:

2023-12-13

Due date:

% Done:

Estimated time:

Tags:

qe-yam-jan-sprint

Description

Motivation¶

In YaST job group for test suite yast2_gui@aarch64 there is a mismatch for needle with tag yast2-security-ui in module yast2_gui/yast2_security.pm:42 that call y2_module_guitest::launch_yast2_module_x11("security", match_timeout => 120);

Scope¶

sle-15-SP6-Online-aarch64-Build44.1-yast2_gui@aarch64

Acceptance criteria¶

AC1: create the needle that match the current $module image, security

Actions

Copy link

Updated by JERiveraMoya about 1 year ago

Tags set to qe-yam-dec-sprint
Status changed from New to Workable
Parent task set to #151816

doesn't need to be a needle, could be a problem re-opening the module or we need to bump timeout.

Actions

Copy link

Updated by JRivrain about 1 year ago

Assignee set to JRivrain

Actions

Copy link

Updated by JRivrain about 1 year ago

Status changed from Workable to In Progress

Actions

Copy link

Updated by openqa_review 12 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: yast2_gui
https://openqa.suse.de/tests/13021643#step/yast2_security/1

To prevent further reminder comments one of the following options should be followed:

The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
The openQA job group is moved to "Released" or "EOL" (End-of-Life)
The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions

Copy link

Updated by JERiveraMoya 12 months ago

Tags changed from qe-yam-dec-sprint, qe-yam-jan-sprint to qe-yam-jan-sprint

Actions

Copy link

Updated by JRivrain 12 months ago

Status changed from In Progress to Blocked

Besides failures in consoletest_setup,the test now fails here https://openqa.suse.de/tests/13195698#step/yast2_security/35 this will require another ticket. blocked for now.

Actions

Copy link

Updated by JERiveraMoya 12 months ago · Edited

Looks like an sporadic problem of pending load of the YaST modules after closing having issues opening it again (we have seen those kind of bugs in the past).

Some suggestion could be to run it separately without the rest of test modules, it might be a bug that something is stuck, but we need to narrow the reproducibility for developers to be able to fix it if we file a bug. Also to see if manually happens somehow.

I noticed we couldn't find the ticket because of "Blocked" status (it is not displayed on purpose in our Sprint backlog).
Is it fine if I/you set to Workable and unassigned or you plan more investigation? thanks.

Actions

Copy link

Updated by JRivrain 12 months ago · Edited

JERiveraMoya wrote in #note-7:

Looks like an sporadic problem of pending load of the YaST modules after closing having issues opening it again (we have seen those kind of bugs in the past).

Some suggestion could be to run it separately without the rest of test modules, it might be a bug that something is stuck, but we need to narrow the reproducibility for developers to be able to fix it if we file a bug. Also to see if manually happens somehow.

I noticed we couldn't find the ticket because of "Blocked" status (it is not displayed on purpose in our Sprint backlog).
Is it fine if I/you set to Workable and unassigned or you plan more investigation? thanks

This: https://openqa.suse.de/tests/13187869 is a different problem than the sporadic failure that is the subject of this ticket. And currently, it is not sporadic, it always happens.

Some suggestion could be to run it separately without the rest of test modules

I obviously did that ! The test run I posted with all modules included is to make sure the exclusion of some modules - like consoletest_setup - is not the cause of the failure.

As-is, it is not "workable" currently, since the described issue cannot be reproduced, and another issue is seen instead. It is not likely to be a product bug, as the same test passed earlier on the same build without that failure.

Actions

Copy link