Actions
action #105043
closedcoordination #104829: [Epic] Improve schedules for test suite in YaST group
Create PoC for YAML schedule with initial ideas
Start date:
2022-01-19
Due date:
% Done:
0%
Estimated time:
Description
Motivation¶
After thinking how to do it in https://confluence.suse.com/display/QYT/Improve+YAML+schedule%3A+remove+duplication and some other additional discussion we could try start to draft this idea. Still is not completely solved. We need to prove that the mechanism can do certain things, so it is time to try something practical and see where we get.
Acceptance criteria¶
AC1: Create executable version with one or more test suite that are representative and are used in different products.
AC2: Develop YAML files for each product with its defaults and YAML schedules using those defaults.
AC3: Explore the possibility to have only one schedule per test suite (Factory First approach)
Further info¶
- To follow a Factory First approach and only have one test schedule per test suite we need to have a mechanism to point to the corresponding file. Schedules in different products are different, so it is clear we need different files, we cannot abstract section or phases of the installer, things are quite different some times to make assumptions. So we need to point to different files, perhaps programmatically.
- We need to probe in this PoC that having all the stages as keys, that those keys are replaced properly.
- The default file in principle is 'runnable', which means we iterate over it and read the values of its keys in the specific schedule we are dealing with where could be some overwrites. If the file is too big, maybe a 'runnable' version is not a good idea (some sort of new main.pm) and we need more like a file with the defaults with no sequences, but then we would have to do the sequences on the specific schedules, which might be tricky as well. We have to evaluate that. Reading in both would avoid the extra syntax with before/after described in confluence, but then we need to repeat the default (we have to evaluate that as well)
- Conditional schedule due to some openQA variables (random ones or combination or distri + arch + virtualization) might be set under those keys, instead of having a dedicated key for conditional schedule
Actions