action #26984
closed
[sle][functional][y] New test scenario: minimal+proxy_SCC-postreg_yast_scc
Added by Anonymous over 6 years ago.
Updated about 5 years ago.
Description
Acceptance criteria¶
- AC1: Have a test scenario for SLE12 to test registration and modules addition using yast_scc against proxy-SCC on ncurses and x11.
- AC2: Have a test scenario for SLE15 to test modules addition using yast_scc against proxy-SCC on ncurses and x11.
Tasks¶
- Adapt SLE12 ncurses tests to register and add modules using yast2_scc using two modules.
- Reuse modules from SLE12 for SLE15, skipping registration module for yast2_scc, since SLE15 is already registered when using yast2_scc.
- Create a new test suite textmode+proxy_SCC-yast2_scc for SLE15
Further details¶
- Related to action #19566: [sle][functional]New test scenario: minimal+proxy_SCC-postreg_suseconnect_scc added
so let's not schedule that one for the next sprint, not yet workable
- Due date set to 2017-11-08
- Status changed from New to In Progress
you stated "should be already done" so with this confidence let's add it.
- Related to action #27028: [sle][functional]test fails in addon_products_via_SCC_yast2 - test does not expect that the system is already registered added
the test module "addon_products_via_SCC_yast2" looks very similar, please take a look in #27028 and crosscheck
- Subject changed from [sle][functional]New test scenario: minimal+proxy_SCC-postreg_yast_scc to [sle][functional] New test scenario: minimal+proxy_SCC-postreg_yast_scc
- Description updated (diff)
Changes on acceptance criteria and tasks because of poo#27028
Actually the scope of this ticket is also affected by legacy tests from SLE12.
- Related to deleted (action #27028: [sle][functional]test fails in addon_products_via_SCC_yast2 - test does not expect that the system is already registered)
- Has duplicate action #27028: [sle][functional]test fails in addon_products_via_SCC_yast2 - test does not expect that the system is already registered added
- Description updated (diff)
- Description updated (diff)
- Blocked by action #27064: [functional][x86_64][s390x][uefi][y][yast][easy] Test suite minimal+base+sdk+proxy_SCC-postreg had a wrong scheduled module list with current version of os-autoinst-distri-opensuse added
- Description updated (diff)
- Due date deleted (
2017-11-08)
not done, needs re-evaluation
- Target version set to Milestone 12
- Assignee deleted (
SLindoMansilla)
Unassigned because it is not in this sprint nor in the next one, to clean my "assigned ticket" list.
- Status changed from In Progress to Workable
- Blocked by action #30706: [sle][functional[sle12 sp4] test fails in boot_to_desktop - needle 'grub2' not found added
- Blocked by deleted (action #30706: [sle][functional[sle12 sp4] test fails in boot_to_desktop - needle 'grub2' not found )
- Description updated (diff)
- Due date set to 2018-04-10
- Status changed from Workable to Blocked
- Target version changed from Milestone 12 to Milestone 15
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: sles+sdk+proxy_SCC_via_YaST
https://openqa.suse.de/tests/1461431
- Assignee set to okurz
- Target version changed from Milestone 15 to Milestone 17
- Subject changed from [sle][functional] New test scenario: minimal+proxy_SCC-postreg_yast_scc to [sle][functional][y] New test scenario: minimal+proxy_SCC-postreg_yast_scc
- Description updated (diff)
- Due date changed from 2018-04-10 to 2018-05-22
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
- Target version changed from Milestone 17 to Milestone 16
- Due date deleted (
2018-05-22)
- Target version changed from Milestone 16 to Milestone 19
Does not have an effect on SLE15 anymore, we can postpone this in favor of other tasks now
- Target version changed from Milestone 19 to Milestone 19
- Due date set to 2018-11-06
- Due date deleted (
2018-11-06)
- Target version changed from Milestone 19 to future
- Status changed from Workable to Rejected
- Assignee set to riafarov
By now we have scenarios covering AC, except that it's not running for ncurses and x11, whereas, knowing how libyui is designed, risks are low that something will break in qt and not in ncurses or vice versa. And if there is such an issue we will notice it for installations handled in qt vs ncurses + other test scenarios where we run tests against both versions (e.g. yast2_lan and yast2_i, which are executed for X11 and ncurses)
Also available in: Atom
PDF