Add git-openqa-maintenance: Review bot for Leap 16+#3271
Conversation
|
Could this bot use the ReviewBot infrastructure from #3247? |
We need to query the source packages of the update to be able to figure out the name of the given staged update, for now we're sticking to the promise that staged updates are single units
Avoid multiple nested ifs, to the code more readable
This is mainly to avoid collisions later on
Build parameter was missing, so query would return all jobs for given parameters
foursixnine
force-pushed
the
openqa-maintenance-leap
branch
from
7bdaf9e to
960263c
Compare
I started looking into it few weeks ago, but upon investing a bit of time in Since the workflows are so different, it felt like a complete separate script (Perhaps also lack of knowledge), so when I started working on a "manual trigger", this ended up becoming a complete separate bot. One example of that is how the approvals are handled, for git projects, instead of using the standard approval process, it is by approving on behalf of a group as comments and another bot does the actual approval |
Hm. Maybe the review bot framework should be adjusted? @YoukouTenhouin |
This is so main_common::is_updates_tests in osado can properly distinguish that the current test is an update to be tested
Yeah, however in the meantime, given that we have maintenance for leap 16 as a hot topic now, I hope we can move forward with this PR, its far from perfect, but has main bits and pieces in there. |
|
I documented the existence of this PR and how one would use that script on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#Scheduling-maintenance-tests-for-openSUSE-Leap-16 so @openSUSE/qa-tools-team is aware of this. What prevents us from merging this PR right now? Would it do anything meaningful in its current state? |
Using a regex is a better way to handle the version string, as it avoids problems with branches like leap-16.0-nonfree
This is used by the tests as a template when installing packages
foursixnine
force-pushed
the
openqa-maintenance-leap
branch
from
4e462fa to
c3e3c1a
Compare
Looking at the section in the wiki, the user running the command needs to also have credentials for the build service being used (~/.config/osc/oscrc)
Somebody with commit access to press the merge button, after a review :)
It would go through all of the prs for one of the projects, I need to add the other two to the gocd config |
I also don't have merge rights in this repo so I cannot help. Maybe @Vogtinator can or knows who we should ping?
Ok, but probably a good first step. I don't have any insights on where this script would be executed (except that your change suggests that some GoCD instance is used). I'd also be interested in the used CI system to see whether it would be feasible to run qem-bot there - for the sake of unifying the code again at some point. If you need any help from @openSUSE/qa-tools-team you can write a comment on https://progress.opensuse.org/issues/190170. |
Setting up the secret in botmaster seems more complicated than reading a plain file, so adding the code to read from a file, and as a fallback read the token from Environment if GITEA_TOKEN_FILE is not set.
|
So, what is missing to have this merged? I'm asking whoever has merge rights in this repo. (I suppose @Vogtinator has merge rights.) It might had made sense to base this on #3247 (or at least reuse code from there). However, currently none of these PRs is making any progress and this one has at least successful CI checks and seems generally further developed. |
5 participants
Extracted from os-autoinst/os-autoinst-scripts#473
This bot is meant to be part of the openSUSE Leap 16+ maintenance release pipeline
The behavior is based on my understanding of what what openqabot does for Leap 15.
It currently will trigger tests based on the status of a build for a given PR, i.e when the autogit_obs_staging_bot approves a PR, it will take into account new pushes to the base branch, only taking into account builds of the most recent commit.
If the tests are already triggered, it will check the status in openQA to know whether to approve or decline based on the test results.