Project

General

Profile

action #115235

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

Added by JERiveraMoya about 2 months ago. Updated 12 days 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.

History

#1 Updated by JERiveraMoya about 2 months ago

  • Description updated (diff)

#2 Updated by JERiveraMoya about 2 months 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

#3 Updated by JERiveraMoya about 2 months ago

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

#4 Updated by JERiveraMoya about 2 months ago

  • Description updated (diff)

#5 Updated by JERiveraMoya about 2 months 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

#6 Updated by JERiveraMoya about 1 month ago

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

#7 Updated by rainerkoenig about 1 month ago

  • Status changed from Workable to In Progress
  • Assignee set to rainerkoenig

#8 Updated by JERiveraMoya 26 days ago

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

#9 Updated by rainerkoenig 22 days 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?

#10 Updated by rainerkoenig 19 days ago

#11 Updated by JERiveraMoya 12 days ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF