Project

General

Profile

coordination #161168

Updated by szarate about 1 month ago

## 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 As a beginning, the support has to be enabled for o3  

  

 ```  
  
 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, and add extra parameters to the isos post, for example `FOO=VAR` TEST 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/ 

 ### Notes  

  ## Suggestions  

  

 There are few considerations to keep in mind:  
  
 1. A hello world script is good enough solution to get started  
  
 2. Solution should allow for the user to alter `isos post` behavior (cli parameters and variables, e.g `BETA=1`)  
  
 3. Solution should allow for multiple hooks to coexist (think how git hooks behave)  

  ## Out of scope  
  * Implementing actual hook scripts usable for the maintenance setup of SLE Micro 6.0 #161750 

Back