Gitlab CI führt Resource Groups ein, um parallele laufende Jobs oder Pipelines automatisch zu koordinieren.
Der Grund für die Änderung: Mitunter sind die Ressourcen von CI/CD-Pipelines begrenzt. Ein Blogpost nennt zum Beispiel Tests von Software auf Mobilgeräten, wenn es nur ein paar Mobilgeräte gibt, auf denen diese Tests laufen. Versuchen nun mehrere Teams ihren Code und ihre Features auf diesen wenigen Mobilgeräten zu testen, kommen sie sich mitunter in die Quere und müssen sich über die Ressourcennutzung absprechen, was die Komplexität erhöht.
Das auf Anregung eines Nutzers hin neu eingeführte “resource_group”-Attribut erlaubt es, wie der Name andeutet, bestimmte Ressourcen in eine Gruppe zu packen. Startet der Initiator der CI/CD-Pipeline dann einen Job, kann er diesen so einer Gruppe zuordnen. Stellt Gitlab CI fest, dass ein laufender Job zu einer Ressourcen-Gruppe gehört, darf parallel kein anderer Job in dieser Resource Group laufen. Parellele Jobanforderungen würde Gitlab dann in eine Warteschlange schieben.
Auch bei mehreren Pipelines
Die Alleinausführung beschränkt sich dabei aber nicht auf Jobs in einer Pipeline. Mitunter wollen Nutzer auch keine Konkurrenz, wenn sie mehrere Pipelines betreiben. Auch das einzurichten, ist neuerdings möglich. Über “.gitlab-ci.yml” lassen sich die Ressourcen-Gruppen definieren.
Die Entwicklung des Features ist dabei noch nicht abgeschlossen, auch bei inkrementellen Deployments könnte das neue Attribut künftig helfen.
