action #180812
Updated by mkittler 27 days ago
## Motivation
As explained in the parent #180806 new maintenance workflows are planned based on [Gitea](https://src.suse.de). SMELT is planned to be adapted right now it is not yet there, see https://gitlab.suse.de/tools/smash/-/issues/1458.
https://gitlab.suse.de/tools/smelt/-/issues/1147, still the plan exists to have a first "dry run" of the SLE 16 maintenance workflow ready by 2025-07-08 as decided as part of #180602. As QE engineers so far rely on features like "approvable_for" comments we should find out if and how feasible an adaptation of qem-bot+qem-dashboard to such workflow is.
## Acceptance criteria
* **AC1:** qem-bot+qem-dashboard is used to trigger+monitor+approve SLE 16 maintenance updates based on src.suse.de
## Suggestions
* Await and incorporate results from spike #180809 and if we can rely on SMELT https://gitlab.suse.de/tools/smash/-/issues/1458
* After #180809#note-14 and [discussions on Slack](https://suse.slack.com/archives/C08DC2SHABV/p1746015720858179) we established the following:
* qem-bot should check PRs on Gitea [like this dummy PR](https://src.suse.de/products/SLFO/pulls/121) using [the Gitea API to list PRs](https://docs.gitea.com/api/1.20/#tag/repository/operation/repoNewPinAllowed) and then do the subsequent actions for each PR.
* "the staging.config file from git" (**whatever that is, this still needs clarification**) and the PR number can be used to determine the project on OBS.
* The OBS-API http://api.suse.de/build/$PROJECT/_result can then be used to determine the build status and affected packages and archs.¹
* If the OBS build status looks good qem-bot can trigger tests.
* How it knows what tests to trigger still needs clarification.
* We could reuse the existing meta-data approach.
* From OBS we know affected packages/archs so we could base the decision on that.
* "yes, that's the updateinfo file, that should be enough for us to know which packages are under test, we just need to parse the xml"
* qem-bot can approve/reject a change by [creating a review on the PR](https://docs.gitea.com/api/1.20/#tag/repository/operation/repoCreatePullReview).
* We should try to keep features mentioned at the end of #180809#note-11 working.
* There will be "staging triggered tests" and "product increment triggered tests", see https://jira.suse.com/browse/MSQA-949. We need to figure out how those match with the current "incidents" and "aggregates". **So this still needs clarification.**
---
¹ It returns a response like this:
```
<resultlist state="c65b1a8b199e10459cde074f2344f51a">
<result project="SUSE:SLFO:1.1.99:PullRequest:121" repository="standard" arch="aarch64" code="unpublished" state="unpublished">
<scmsync>https://src.suse.de/bfilho/SLFO.git?onlybuild=supportutils#72f75791e9905f2b4954006365fe2a6f7bb81001cc5e7b31cf19be8dffdc000c</scmsync>
<scminfo>72f75791e9905f2b4954006365fe2a6f7bb81001cc5e7b31cf19be8dffdc000c</scminfo>
<status package="supportutils" code="succeeded"/>
</result>
<result project="SUSE:SLFO:1.1.99:PullRequest:121" repository="standard" arch="ppc64le" code="unpublished" state="unpublished">
<scmsync>https://src.suse.de/bfilho/SLFO.git?onlybuild=supportutils#72f75791e9905f2b4954006365fe2a6f7bb81001cc5e7b31cf19be8dffdc000c</scmsync>
<scminfo>72f75791e9905f2b4954006365fe2a6f7bb81001cc5e7b31cf19be8dffdc000c</scminfo>
<status package="supportutils" code="succeeded"/>
</result>
<result project="SUSE:SLFO:1.1.99:PullRequest:121" repository="standard" arch="x86_64" code="unpublished" state="unpublished">
<scmsync>https://src.suse.de/bfilho/SLFO.git?onlybuild=supportutils#72f75791e9905f2b4954006365fe2a6f7bb81001cc5e7b31cf19be8dffdc000c</scmsync>
<scminfo>72f75791e9905f2b4954006365fe2a6f7bb81001cc5e7b31cf19be8dffdc000c</scminfo>
<status package="supportutils" code="succeeded"/>
</result>
</resultlist>
```