[y] Generate dud file dynamically instead of relying on urls
Test fails because the ftp://openqa.suse.de/SLE-15-Module-Development-Tools-POOL-x86_64-Media1-CURRENT is not available.
Validation and setup are introduced in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10770/files but we need a better approach.
We have https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data/dev_tools.dud which is basically tarball created with
mkdud. Detailed steps are described here:
As per comment below, we have option to pre-install
mkdud tool on all 64bit workers, which is a bit of an overkill, but solves the issue: https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/server.sls
As an alternative we can use chained jobs and boot into installed image and generate the dud. To make it more stable we could have used support server image here.
See http://open.qa/api/testapi/#_upload_asset for uploading asset.
REPO_SLE_MODULE_DEVELOPMENT_TOOLS variable contains the name of the repo.
openQA test in scenario sle-15-SP3-Online-x86_64-dud_development_tools@64bit fails in
Test suite description¶
Same as dud_sdk, but due to bsc#1080292 we cannot use ISO. FTP url is used instead. Limitation is that we use x86_64 url, as cannot create DUD in the runtime, so test cannot be executed on other architectures.
Fails since (at least) Build 18.1
Last good: 18.1 (or more recent)
Always latest result in this scenario: latest
#2 Updated by riafarov about 1 year ago
Idea is to generate dud file with correct url, whereas mkdud is not installed on the workers, so it's not an option right now. inst-sys also doesn't contain it, so the only feasible way atm is to boot some machine, generate dud and upload it as an asset, which will be used by the current test, similarly like we do for autoyast_reinstall scenario.
#7 Updated by JERiveraMoya about 1 year ago
- Status changed from In Progress to Feedback