[functional][u][y][epic] improve openqa triggering mechanisms, standardize OBS/IBS deliverables structure, trigger jobs using other means
|Category:||Enhancement to existing tests|
|Target version:||QA - future|
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
As an openQA user I want to trigger CI jobs using integrated tools in OBS/openQA itself.
- 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
- 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.
#3 Updated by okurz over 1 year 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
This story might also be related to what @coolo mentioned as the "facehugger" endeavour which involves the OBS team and REs at least.
#9 Updated by okurz over 1 year 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.
- 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
- 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.
- 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]".