Project

General

Profile

Actions

action #42917

closed

coordination #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 5 years ago. Updated over 3 years ago.

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

0%

Estimated time:
5.00 h

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 1 (0 open1 closed)

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

Actions
Actions #1

Updated by okurz over 5 years 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
Actions #2

Updated by riafarov over 5 years ago

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

Updated by JERiveraMoya over 5 years ago

  • Status changed from Workable to In Progress
  • Assignee set to JERiveraMoya
Actions #4

Updated by JERiveraMoya over 5 years 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

Actions #5

Updated by JERiveraMoya over 5 years 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.

Actions #6

Updated by JRivrain over 5 years 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)

Actions #7

Updated by JERiveraMoya over 5 years ago

  • Status changed from Feedback to Resolved
Actions #8

Updated by okurz over 5 years ago

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

Updated by okurz over 5 years 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

Actions #10

Updated by JERiveraMoya over 5 years 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.

Actions #11

Updated by riafarov over 5 years 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.

Actions #12

Updated by JERiveraMoya over 5 years ago

  • Status changed from Workable to In Progress
Actions #13

Updated by JERiveraMoya over 5 years 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
Actions #14

Updated by JERiveraMoya over 5 years 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.

Actions

Also available in: Atom PDF