QA » openQA Project

Motivation¶

See Discussion in https://suse.slack.com/archives/C02CANHLANP/p1716882218853889 and #159828-9

In general there is the need to be able to hook into different stages of how OBS Sync plugin works, or an alternative solution that allows a release manager or maintenance coordinator (with help of QE) to dynamically select/alter the test variables and openqa cli parameters, using a script.

• Main focus would be before and after the iso post is done, So that via hook, we could alter test schedules for a given build, based on the information contained by the assets (or other places where the owner of the hook has control)
• before and after syncing assets is secondary, so that administrator/anybody else, can do fancy things if needed

Intent¶

The intention here is to be able to dynamically select a set of tests or jobgroups to include in the isos post based on information provided either by patchinfo or available in the obs/ibs repository. In the beginning, the support has to be enabled for o3 (i.e Tumbleweed, with @dimstar as a stakeholder)

 So, the requirement we would need from this tool is to read and parse the information from the staging repo (patchinfo) or information available in the obs project, add extra parameters to the isos post, for example `FOO=VAR` variable o _GROUP_ID depending on which packages are to be tested. This way, we can customize which set of tests are triggered for specific packages. e.g. trigger kernel-ltp tests for kernel updates and skip them otherwise (similar to metadata incident config in bot-ng). 

Acceptance criteria¶

• AC1: A "hello world" hook script can be called before actual "isos post" calls in https://github.com/os-autoinst/openqa-trigger-from-obs/
• AC2: hook scripts execution can be skipped based on configuration variables, e.g. from the .xml files in https://github.com/os-autoinst/openqa-trigger-from-obs/
• AC3.1: Solution should allow for the user to alter isos post behavior (cli parameters and variables, e.g BETA=1)
• AC3.2: Solution should allow for multiple hooks to coexist (think how git hooks behave)

Notes¶

Out of scope¶

• Implementing actual hook scripts, other than the hello world example (reference). #161750