action #115235
closed[Timebox: 24h] Investigate how to make Gitlab CI work for more than 1 job group
0%
Description
Motivation¶
During SLE-15-SP4 we had plenty of issues with the infrastructure in particular, networking, svirt-hyperv machines, remote workers rebooting issues like in PowerVM and so on. We should be able to move configuration to a Development group and of course mention weekly what we are excluding. It is not planned to exclude everything, like we do more strictly in Maintenance Updates, but at least to have an easy way to move configuration and make our life easier when reviewing openQA.
Currently it is not the case for Product validation, the CI only is ready for update one job group yaml.
https://gitlab.suse.de/qsf-y/qa-sle-functional-y
CI in maintenance would allow us to do that, but it is using json instead of yaml, making really slow the web ui, as all the test suites are stored in db. Also it is not trivial to figure out the settings required for a test suite when migrated from its declaration using yaml to its declaration using json. Making possible to work with more than one job group will have a lot of advantages, among them, we could consider unify CI with migration in https://gitlab.suse.de/coolgw/wegao-test/
Acceptance criteria¶
AC1: Figure out what would be the required changes
Suggestions¶
If trivial, implement it as a PoC, if not create follow-up tickets.
Quickly looking at the code we could see that we might need to rename this folder to represent YaST group, create another folder which represent the name of another job group and iterate over that. It would be great to not have hardcoded the group id and have a yaml file to specify them.