Project

General

Profile

Actions

action #115235

closed

[Timebox: 24h] Investigate how to make Gitlab CI work for more than 1 job group

Added by JERiveraMoya over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-08-11
Due date:
% Done:

0%

Estimated time:

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.

Actions #1

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #2

Updated by JERiveraMoya over 1 year 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
Actions #3

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
  • Status changed from Workable to New
Actions #4

Updated by JERiveraMoya over 1 year ago

  • Description updated (diff)
Actions #5

Updated by JERiveraMoya over 1 year 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
Actions #6

Updated by JERiveraMoya over 1 year ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable
Actions #7

Updated by rainerkoenig over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to rainerkoenig
Actions #8

Updated by JERiveraMoya over 1 year ago

Consider existing CI for migration already applies it:
https://gitlab.suse.de/coolgw/wegao-test/-/blob/master/.gitlab-ci.yml

Actions #9

Updated by rainerkoenig over 1 year 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?
Actions #10

Updated by rainerkoenig over 1 year ago

Actions #11

Updated by JERiveraMoya over 1 year ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF