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.
Updated by JERiveraMoya over 2 years ago
- Subject changed from [Research: 24h] Investigate how to make Gitlab CI work for more than 1 job group to [timebox: 24h] Investigate how to make Gitlab CI work for more than 1 job group
Updated by JERiveraMoya over 2 years ago
- Description updated (diff)
- Status changed from Workable to New
Updated by JERiveraMoya over 2 years ago
- Subject changed from [timebox: 24h] Investigate how to make Gitlab CI work for more than 1 job group to [Timebox: 24h] Investigate how to make Gitlab CI work for more than 1 job group
Updated by JERiveraMoya over 2 years ago
- Tags deleted (
qe-yast-refinement) - Status changed from New to Workable
Updated by rainerkoenig over 2 years ago
- Status changed from Workable to In Progress
- Assignee set to rainerkoenig
Updated by JERiveraMoya over 2 years ago
Consider existing CI for migration already applies it:
https://gitlab.suse.de/coolgw/wegao-test/-/blob/master/.gitlab-ci.yml
Updated by rainerkoenig over 2 years ago
Investigation notes¶
Current handling for migration¶
- The migration job group repo uses just one YAML file per job group.
- GitLab CI triggers on merge requests and when specific job group YAML is changed.
Current handling for YaST¶
- in the YaST job group repo we have one directory for the job group that holds the defaults and one YAML per architecture.
- GitLab CI triggers on merge requests and when any file under JobGroups changes or even if .gitlab-ci.yml changes.
Suggestion for a YaST devel job group¶
- create a YaST_devel job group and put its number in the CI as GROUP_ID_SLE15_DEVEL.
- keep the directory per job group approach and create e.g. SLE_15_devel directory to hold the YAML files.
- Duplicate the current CI approach for the devel group.
- Make triggers more specific to each group, so that only those parts of the CI will run when files in a job group have changed.
- discuss if we should remove .gitlab-ci.yml from the triggers?
Updated by rainerkoenig over 2 years ago
MR to review (but not to merge) is ready: https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/merge_requests/417
Updated by JERiveraMoya about 2 years ago
- Status changed from In Progress to Resolved