action #115565
closedcoordination #111347: [saga][epic] Properly maintained Maintenance QA tooling
coordination #110884: [epic] Properly maintained open source mtui+oscqam
Setup OBS integration for openSUSE/mtui and openSUSE/osc-plugin-qam size:M
0%
Description
Motivation¶
With #111338#note-15 the mtui project lives on GitHub. However packaging lives in IBS and requires a manual step to push out releases. It would be much better to have a project on OBS with proper GitHub integration. The same holds for osc-plugin-qam.
Acceptance criteria¶
- AC1: mtui is packaged on OBS
- AC2: osc-plugin-qam is packaged on OBS
- AC3: No manual steps are required to trigger releases
Suggestions¶
- Create a new project (namespace) to host both devel packages or alternatively place them under devel:openQA.
- Enable the SCM bridge i.e. add
<scmsync>https://github.com/openSUSE/mtui</scmsync>
Updated by livdywan over 2 years ago
- Copied from action #111338: Open source https://gitlab.suse.de/qa-maintenance/mtui size:M added
Updated by livdywan over 2 years ago
- Priority changed from Low to Normal
- Target version deleted (
Ready)
I didn't meant to specify Priority or Target version here, leaving that to the (acting) PO
Updated by jbaier_cz over 2 years ago
- Subject changed from Setup OBS integration for openSUSE/mtui to Setup OBS integration for openSUSE/mtui and openSUSE/osc-plugin-qam
- Description updated (diff)
I added mention about osc-plugin-qam. Also, I already have mtui and osc-plugin-qam in my home project, so I can push them if needed.
Updated by jbaier_cz over 2 years ago
- Related to action #111341: Open source https://gitlab.suse.de/qa-maintenance/qam-oscplugin/ size:M added
Updated by livdywan over 2 years ago
- Subject changed from Setup OBS integration for openSUSE/mtui and openSUSE/osc-plugin-qam to Setup OBS integration for openSUSE/mtui and openSUSE/osc-plugin-qam size:M
- Status changed from New to Workable
Updated by jbaier_cz about 2 years ago
- Status changed from Workable to In Progress
- Assignee set to jbaier_cz
Updated by openqa_review about 2 years ago
- Due date set to 2022-10-11
Setting due date based on mean cycle time of SUSE QE Tools
Updated by jbaier_cz about 2 years ago
I tried to play a little with the scm bridge integration; it is working somehow, although the sync is not really fast. Unfortunately, it will need a lot of changes in the repository (including and maintaining a proper specfile among others). It seems to me that the simpler choice would be to just include a Github workflow calling obs with a token (as was done in Gitlab).
Updated by livdywan about 2 years ago
jbaier_cz wrote:
I tried to play a little with the scm bridge integration; it is working somehow, although the sync is not really fast. Unfortunately, it will need a lot of changes in the repository (including and maintaining a proper specfile among others). It seems to me that the simpler choice would be to just include a Github workflow calling obs with a token (as was done in Gitlab).
Can you expand on this a bit? Maybe we can approach OBS devs with this feedback.
Updated by jbaier_cz about 2 years ago
It is basically summarized in the SCM bridge documentation already:
Any source processing by source services is not supported by design. All source management, review and merge handling needs to happen on the SCM side.
The repository is cloned including all subdirectories, but the build descriptions need to be available on top level.
Those two points are easier to comply with if you start a new project with this knowledge; with our approach regarding mtui, it is a little bit to much work to have the spec file in the repository and bump the version on every commit to have it rebuild and maintained a tagged versions with different spec file (because we have stable and test releases) over the so far used alternative "osc co, osc service, osc ci" inside CI and letting the OBS to do the work.
So I am not saying that the SCM bridge is inherently bad idea, it could be great for some types of projects. For us, it would mean to invest some work to recreate some part of OBS automation inside GitHub workflow, not worth it in my opinion.
Updated by jbaier_cz about 2 years ago
So I created devel:openQA:Tools/osc-plugin-qam and devel:openQA:Tools/mtui, two tokens for triggering the service in OBS and webhook configuration in Github to use those token to trigger the service after push. So now, every push into main/master branch should result in a new version of the tool.
Updated by livdywan about 2 years ago
jbaier_cz wrote:
So now, every push into main/master branch should result in a new version of the tool.
Here's a trivial PR to test the theory: https://github.com/openSUSE/mtui/pull/3
Updated by jbaier_cz about 2 years ago
- Due date deleted (
2022-10-11) - Status changed from In Progress to Resolved