coordination #36778
closed[functional][u][y][epic] improve openqa triggering mechanisms, standardize OBS/IBS deliverables structure, trigger jobs using other means
0%
Description
Motivation¶
As an outcome of #35766 we have decided following:
- we will try to avoid investing time in rsync.pl but look for better integration with openQA
- rsync.pl logic is complicated mainly because isos and repos are published using quite different structure for each distri
- we cannot make most of the repo content public as it contains internal infrastructure details
User story¶
As an openQA user I want to trigger CI jobs using integrated tools in OBS/openQA itself.
Acceptance criteria¶
- AC1: openSUSE contributors acting as release managers for openSUSE ports have access to all code that is executed for building, publishing, syncing, triggering
- AC2: Anyone can find the current status of builds+tests without needing to ask people to login to VMs over ssh
Suggestions¶
- Collect opinions of stakeholders, e.g. openSUSE and SLE RMs, REs as well as PMs, e.g. coolo, DimStar, lnussel, michel_mno (ppc oS ports), dirk (aarch64 oS ports), guillaume_g (aarch64 oS ports), boombatower/jimmyberry (release engineer), maxlin, adrianS (OBS PO), ro
- Evaluate complexity and efforts to make publishing structures same for openSUSE repos, and then same for SLE
- Evaluate idea of integration of triggering mechanisms in OBS/IBS or openQA using api calls, etc.
References¶
Updated by riafarov almost 6 years ago
- Related to action #35766: [functional][y][medium] improve openqa/scripts - Feasibility: Make openqa/scripts open source if possible, feasible and beneficial added
Updated by riafarov almost 6 years ago
- Assignee set to okurz
@okurz, please take a look. I guess we can start with collecting problems people have. Could you please help to identify stakeholders then? Thanks!
Updated by okurz almost 6 years ago
- Subject changed from [functional][epic] improve openqa triggering mechanisms, standartize OBS/IBS deliverables structure, trigger jobs using other means to [functional][epic] improve openqa triggering mechanisms, standardize OBS/IBS deliverables structure, trigger jobs using other means
- Description updated (diff)
- Category set to Enhancement to existing tests
added list of stakeholders
@riafarov two hints regarding formatting in redmine
- for a list put a blank line separating the previous content from the list unless it's a title to make it look nice
- Reference other tickets in the format
#<id>instead of[poo#<id>](https://…/issues/<id>)
This story might also be related to what @coolo mentioned as the "facehugger" endeavour which involves the OBS team and REs at least.
Updated by okurz almost 6 years ago
- Target version changed from future to future
Updated by okurz almost 6 years ago
- Related to deleted (action #35766: [functional][y][medium] improve openqa/scripts - Feasibility: Make openqa/scripts open source if possible, feasible and beneficial)
Updated by okurz almost 6 years ago
- Related to coordination #34102: [functional][y][epic] improve openqa/scripts added
Updated by okurz almost 6 years ago
- Related to action #10516: [functional][u] Use jenkins as extension for openQA added
Updated by okurz almost 6 years ago
For the holistic approach and "scaling up" right now I can think of two solutions:
- Use an existing CI as a main entry point and use OBS and openQA to do the individual tasks
- Connect all individual services by AMQP and try to find a solution which can visualize these connections
An example for 1. is #10516 based on jenkins, a good alternative might be gitlab with its pipeline based CI (and e.g. kubernetes backend).
For "scaling down" we can think of what minimums are required to run a single openQA test scenario or module triggered by e.g. a single package build and test, e.g. OBS builds a package, a specific openQA test is triggered for that and feedback is provided within than OBS project to the maintainers. Or in a github project travis job.
Updated by okurz over 5 years ago
- Subject changed from [functional][epic] improve openqa triggering mechanisms, standardize OBS/IBS deliverables structure, trigger jobs using other means to [functional][u][y][epic] improve openqa triggering mechanisms, standardize OBS/IBS deliverables structure, trigger jobs using other means
Updated by okurz over 5 years ago
- Blocked by action #37447: [functional][y][medium] improve openqa/scripts - Replace openqa/scripts by an open source solution (or open source itself) added
Updated by okurz almost 5 years ago
- Assignee changed from okurz to mgriessmeier
Move to new QSF-u PO after I moved to the "tools"-team. I mainly checked the subject line so in individual instances you might not agree to take it over completely into QSF-u. Feel free to discuss with me or reassign to me or someone else in this case. Thanks.
Updated by okurz almost 5 years ago
- Assignee changed from mgriessmeier to riafarov
@riafarov I guess I could take this over to the "tools"-team only I hesitated to do so because you are the author of the ticket. Would you like to keep it within QSF-y? Otherwise feel free to replace "[functional][u][y]" with "[tools]".
Updated by okurz almost 4 years ago
- Status changed from Blocked to Feedback
The blocker had been resolved a long time ago. With https://github.com/os-autoinst/openqa-trigger-from-obs we now have a project that should be covered by more than one person.
@riafarov Would you agree this task is done or do you see something missing?
Updated by szarate over 3 years ago
- Tracker changed from action to coordination
Updated by szarate over 3 years ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html
Updated by riafarov over 3 years ago
- Status changed from Feedback to Closed
This is done by obs trigger plugin implemented by tools team.
Updated by okurz over 3 years ago
For the sake of completeness there was more than just "obs trigger plugin", e.g.
- AC1: openSUSE contributors acting as release managers for openSUSE ports have access to all code that is executed for building, publishing, syncing, triggering
yes, this is true due to a github project for o3 and a corresponding gitlab.suse.de project for osd. Also in the meantime we can give ssh access to non-SUSE employees following https://progress.opensuse.org/projects/openqav3/wiki/#Accessing-o3-infrastructure as o3 is reachable over "gate.opensuse.org", i.e. not relying on any SUSE internal network connection.
- AC2: Anyone can find the current status of builds+tests without needing to ask people to login to VMs over ssh
with the obs trigger UI plugin everyone with access to the webUI of an openQA instance has a convenient entry point to see the current status of "sync+trigger" for configured products.