Project

General

Profile

action #42917

action #42854: [functional][y][epic] Introduce relevant installation validation test modules

[sle][functional][y] Introduce only relevant tests modules for USBinstall test suite

Added by riafarov over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Enhancement to existing tests
Target version:
SUSE QA tests - Milestone 22
Start date:
2018-10-25
Due date:
2018-12-03
% Done:

0%

Estimated time:
5.00 h
Difficulty:
Duration: 28

Description

Motivation

We already execute same set of test suites on the same setup, except the fact that USB used for installation. So USBinstall test suite performs a lot of actions and creates review overhead not bringing much value.

We need to identify relevant set of test modules, which can be affected by having repo on, e.g. zypper tests, yast_i, updates

Acceptance criteria

  1. Set of test modules is defined based on the business value of scenario and confirmed by stackholders
  2. Only relevant test modules are scheduled in the scenario.

Suggestions

INSTALLATION_VALIDATION=... can be used here. We can ask yast team (#yast irc channel on freenode) and RMs.


Related issues

Related to openQA Tests - action #44708: [sle][functional][y] test fails in enable_usb_repo - Unschedule enable_usb_repoResolved2018-12-042018-12-18

History

#1 Updated by okurz over 1 year ago

  • Subject changed from [sle][functional][y] Introduce only relevant tests modules for USBintall test suite to [sle][functional][y] Introduce only relevant tests modules for USBinstall test suite
  • Category set to Enhancement to existing tests

#2 Updated by riafarov over 1 year ago

  • Description updated (diff)
  • Estimated time set to 5.00 h

#3 Updated by JERiveraMoya over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to JERiveraMoya

#4 Updated by JERiveraMoya over 1 year ago

  • Status changed from In Progress to Feedback

Question asked in #yast channel but no answer atm.
In SLE-15 we assume that the first repo is usb, but it is not the case:
PR - Fix search usb repo number when not first

#5 Updated by JERiveraMoya over 1 year ago

I was discussing this task with @JRivrain and the steps involved, once is merged he already have permission in OSD for setting up the test suite and provide the verification. Waiting for PR review.

#6 Updated by JRivrain over 1 year ago

Parameters added in test suite, and test suite moved to yast group.
VR :
https://openqa.suse.de/tests/2298563
https://openqa.suse.de/tests/2298564
(in progress)

#7 Updated by JERiveraMoya over 1 year ago

  • Status changed from Feedback to Resolved

#8 Updated by okurz over 1 year ago

  • Related to action #44708: [sle][functional][y] test fails in enable_usb_repo - Unschedule enable_usb_repo added

#9 Updated by okurz over 1 year ago

  • Due date changed from 2018-12-04 to 2018-12-18
  • Status changed from Resolved to Workable
  • Priority changed from Normal to Urgent

As described in #44708#note-6 reopening to handle the direct regression which dimstar first mentioned in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6324#issuecomment-444058428

#10 Updated by JERiveraMoya over 1 year ago

I don't think it is a regression, it is more a false positive. The PR just made it more explicit showing a problem that was hidden: We were enabling the first repo which was not usb and was already enabled (because there are not usb repos in ths scenario).
There is no need for this test on that testsuite and possible bad use of the variable USBBOOT.

#11 Updated by riafarov over 1 year ago

I also believe that it depends on the point of view. Objectively this change has exposed problem we always had. In the end I don't care how we solve this, I was fine with the new ticket. I also want to emphasize that JERiveraMoya has identified this problem and created ticket, that's really well done and shows that we cared about potential issues. So thanks for that! As for ticket, please handle it any way you comfortable with, either here, or we can use the one you've created and anyone from the team can pick it up.

#12 Updated by JERiveraMoya over 1 year ago

  • Status changed from Workable to In Progress

#13 Updated by JERiveraMoya over 1 year ago

  • Due date changed from 2018-12-18 to 2018-12-03
  • Status changed from In Progress to Resolved
  • Priority changed from Urgent to Normal

#14 Updated by JERiveraMoya over 1 year ago

thanks, what I was thinking is exactly how you put it. For me is easier to handle in that way, so I revert it, also I labeled the corresponding failing job with the other ticket the other day, so it is less messy now.

Also available in: Atom PDF