action #38732
closed[sle][functional][y] test fails in addon_products_sle - Add hint to test if ADDONURL isn't set
0%
Description
Observation¶
openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-skip_registration+workaround_modules@uefi as well as scenario sle-15-SP1-Installer-DVD-x86_64-Build13.2-skip_registration+workaround_modules@64bit both fail in applying their workaround of adding all modules as add-on over FTP. See addon_products_sle (SLE15SP1) compared to addon_product_sle (SLE15SP0).
This is quiet hard to debug for a reviewer since the visible issue ("GNOME does not start") is not directly linked to the root-cause: "ADDONURL is not set, therefore we don't install every module as Add-On". Even worse: the workaround gets skipped in the module addon_product_sle while the fail is only visible many modules later at the last step.
@okurz mentioned that the required variables (see "Expected result" for an example) get dynamically added with rsync.pl (which does some kind of availability check beforehand). We should take care to mention the result of this availability check later in tests. Especially if they require these variables to run properly.
Reproducible¶
Fails since Build 13.2 (SLE15SP1) (current job)
Expected result¶
The two test should get scheduled with the correct variables set.
One of those variables is e.g. ADDONURL ("base,desktop,serverapp,script" in SLE15SP0).
Acceptance criteria¶
- AC1: A test module fails when ADDONURL can not be set
Suggestions¶
There is already code in the sle main.pm to set the addons dynamically based on the repos but that should be moved into the first module that actually uses the addons so that a fail would not incomplete the jobs (aborted in main.pm evaluation) but the module
Further details¶
Always latest result in this scenario: latest
Updated by okurz over 5 years ago
- Related to action #38453: SP1 stagings don't get addon repos added
Updated by okurz over 5 years ago
- Due date set to 2018-07-31
- Status changed from New to In Progress
- Assignee set to okurz
- Target version set to Milestone 18
Same symptom as in #38453 , in autoinst-log.txt: "Use of uninitialized value $addonurl in substitution (s///) at /var/lib/openqa/cache/tests/sle/products/sle/main.pm line 299." -> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5407
Updated by okurz over 5 years ago
- Status changed from In Progress to Closed
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5407 merged. Showing up as incomplete in https://openqa.suse.de/tests/1857778/file/autoinst-log.txt which is not nice but maybe better than failing in first_boot and pointing to something wrong about the repos.
How about we move this addon setting into a test module which then fails properly instead of the main? Like isosize?
@rwx788, coolo?
Updated by riafarov over 5 years ago
- Status changed from Feedback to Resolved
I consider this is done.
Updated by okurz over 5 years ago
- Status changed from Resolved to Feedback
well, that is not really an answer I expected. I would appreciate if you relate more to my questions
Updated by riafarov over 5 years ago
- Due date changed from 2018-07-31 to 2018-08-14
Updated by riafarov over 5 years ago
- Subject changed from [sle][functional][y][fast] test fails in addon_products_sle - Add hint to test if ADDONURL isn't set to [sle][functional][y] test fails in addon_products_sle - Add hint to test if ADDONURL isn't set
Updated by riafarov over 5 years ago
I don't think we need to have separate test module, but rather in place where it's used.
Updated by okurz over 5 years ago
- Description updated (diff)
- Due date changed from 2018-08-14 to 2018-09-11
- Status changed from Feedback to Workable
- Assignee deleted (
okurz) - Target version changed from Milestone 18 to Milestone 19
Updated by mloviska over 5 years ago
- Status changed from Workable to In Progress
- Assignee set to mloviska
Updated by mloviska over 5 years ago
Updated by mloviska over 5 years ago
- Status changed from In Progress to Feedback
Updated by riafarov over 5 years ago
- Status changed from Feedback to Resolved
Code is merged, as it doesn't fail won't see on production. Hence resolving.