Project

General

Profile

action #154498

Updated by okurz 10 months ago

## Motivation 
 One of the most important responsibilities within SLE maintenance testing is to approve/reject SLE maintenance release requests based on openQA test results. So far [qem-bot](https://github.com/openSUSE/qem-bot) is sufficient to schedule openQA tests but merely does a mediocre job of reporting back results as test results are asynchronously polled based on a periodic schedule https://gitlab.suse.de/qa-maintenance/bot-ng/-/pipeline_schedules causing unnecessary delays, inefficient polling, using outdated results #122311 and not even reporting back on blocking test failures #97121. Let's use a proper architecture with efficient event based triggers providing relevant information back to release requests on IBS using core openQA features rather than too much custom lacking downstream tooling: Develop a proof-of-concept of listening to yet-to-be designed "openQA product build testing finished" AMQP events and approve/reject the according release request. 

 ## Suggestions 
 * Research how common OBS checks are implemented, e.g. openQA staging test integration, legalreview, installcheck, etc. For this see https://github.com/openSUSE/opensuse-release-tools 
   * Read https://github.com/openSUSE/openSUSE-release-tools/blob/master/gocd/rabbit-openqa.py 
   * Read https://github.com/openSUSE/openSUSE-release-tools/blob/master/gocd/rabbit-repoid.py 
 * Follow #152939 and add publishing for an AMQP event for when incident "foo" finishes testing in openQA. For finding all tests related to incident "foo" see #117655 
 * Integrate both of the above either in a new standalone application or hack into https://github.com/openSUSE/qem-bot – as part of a spike solution so do not be afraid to break any other use case – to approve/"reject" SLE maintenance release requests. If "reject" seems to be too severe then provide only "informational" feedback, e.g. as IBS comment or checker result. 
 * Optionally consider to implement this as a openQA plugin, maybe that is simpler for some cases 

 ## Further details 
 Also related to #122311, #123088, #97121, #99303, #152939, #131279, #117655 

 ## Out of scope 
 * Where to run persistently

Back