action #115565
closed
coordination #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
Added by livdywan over 1 year ago.
Updated over 1 year ago.
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>
- Copied from action #111338: Open source https://gitlab.suse.de/qa-maintenance/mtui size:M added
- 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
- Description updated (diff)
- 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.
- Target version set to Ready
- Related to action #111341: Open source https://gitlab.suse.de/qa-maintenance/qam-oscplugin/ size:M added
- 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
- Status changed from Workable to In Progress
- Assignee set to jbaier_cz
- Due date set to 2022-10-11
Setting due date based on mean cycle time of SUSE QE Tools
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).
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.
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.
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.
- Due date deleted (
2022-10-11)
- Status changed from In Progress to Resolved
Also available in: Atom
PDF