Project

General

Profile

Actions

action #105043

closed

coordination #104829: [Epic] Improve schedules for test suite in YaST group

Create PoC for YAML schedule with initial ideas

Added by JERiveraMoya almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
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

Also available in: Atom PDF