coordination #40979: [sle][functional][y][epic] New test strategy for autoyast profiles from ay-tests repo
[sle][functional][y][timeboxed:16h] Establish pipeline for autoyast testing
As QA engineer I would like to test product early too. After discussion with YaST we have agreed that we need to re-enable tests for autoyast before these reach staging.
For quite some time they were not executed, and now our proposal would be to reuse same approach we have in openQA.
- There is a PoC pipeline for testing YaST package(s) during development->staging->build
#3 Updated by okurz over 2 years ago
If I understand correctly this ticket is what is also mentioned as an example in #42218 . If it is true that the YaST development team abandoned the autoyast integration tests then I am not convinced we should care either. They might have good reasons but I do not see it would be useful if they do the development part and we cover "their" testing. How can we clarify this?
#7 Updated by okurz over 2 years ago
- Subject changed from [sle][functional][y][timeboxed:8h] Establish pipeline for autoyast testing to [sle][functional][y] Establish pipeline for autoyast testing
I suggest to call
isotovideo from os-autoinst. Keep in mind that
isotovideo also supports to be called without a vars.json file by specifying all necessary parameters as command line parameters, e.g.
isotovideo -d productdir=$(pwd) version=foo distri=bar
#11 Updated by riafarov over 2 years ago
- Assignee deleted (
I was not able to fully work on it, so un-assign myself for now and here is the current summary:
- Packages do not have cycle dependencies, so we can run CI rebuilding single package + YaST:Head used as an update repo.
- Conclusion from the point above is that we can run CI per PR
- For AY we can use openQA as a good fitting tool.
- For other packages we should wait till we get YaST UI testing framework.
- Unit tests is still must have and we should cover as much as possible to get fast and easrly feedback.
- To improve investigation we should always the iso with which we are sure that CI works if executed without recent changes.
- There are concerns as jenkins nodes we have currently won't be capable to run heavy jobs, we have to try.
Here are more details about infrastructure:
These machines are:
The root password is listed in the YaST/Jenkins wiki page. However, it
would be a good thing to have your SSH public keys added to the
authorized_keys just in case we change the password or the authentication
method in the future (you can send me your public keys and I will take care).
Finally, it would be great if you can document all the steps so we can add
them to our Salt configuration. Actually, if you plan to set more than one
machine, we could use Salt to configure the rest.