Euer Team hat also begonnen, GitLab zu nutzen – selbst verwaltet, dediziert oder sogar auf gitlab.com. Ihr habt für alle eure Repositories CI/CD geschrieben und, wie vielerorts empfohlen, dafür ein dediziertes Repository erstellt, das andere Repositories als Template referenzieren. Doch nun stoßt ihr auf einige Probleme. Das gesamte Repository zu dokumentieren, ist ebenso aufwendig wie die Suche nach relevanten Informationen. Ihr müsst dafür passende Wiki-Seiten pflegen, und jemand muss die Verantwortung dafür übernehmen und sie aktualisieren. Diese Aufgabe ist mühsam und wird nicht optimal gelöst.
Jae Lo Presti
Jae "J4" Lo Presti is a senior consultant working at Eficode in Helsinki, Finland, centred around Git forges such as GitLab and GitHub.
Was ist eine Komponente?
GitLab-Komponenten vereinfachen all das. Komponenten wurden mit GitLab 17.0 allgemein eingeführt und ermöglichen euch einen Katalog von CI/CD-Komponenten, die ihr einfach und direkt in jedem Repository eurer Organisation nutzen könnt.
„Aber Moment!“, sagt ihr zu mir, „wir haben all diese CI/CD-Pipelines bereits geschrieben. Warum sollten wir uns die Mühe machen, alles für ein neues System neu zu schreiben? Das kostet Zeit und Aufwand, und wir müssen alles erneut dokumentieren.“
Genau hier kommt die Magie von GitLab-Komponenten ins Spiel: Eure bestehenden CI/CD-Pipelines müssen nur minimal angepasst werden.
Eure erste Komponente
Sehen wir uns folgende CI/CD-Vorlage an: Angenommen, ihr möchtet eine .NET-9-Anwendung bauen und die Binärdateien anschließend im internen GitLab-NuGET-Repository veröffentlichen:
.nuget:publish:
stage: publish
image: mcr.microsoft.com/dotnet/sdk:9.0
only:
- tags
- $FORCE_PUBLISH == "true
script:
- dotnet pack -c release
- dotnet nuget add source
${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text - dotnet nuget push "**/bin/Release/*.nupkg" --source gitlab
Kurz gesagt: Wenn ein Tag veröffentlicht wird oder die Variable FORCE_PUBLISH auf „true“ gesetzt ist, packt die Pipeline das Projekt, fügt das GitLab-NuGET-Repository hinzu und überträgt die gepackten Daten dorthin.
Diese Pipeline in eine Komponente umzuwandeln, ist ganz einfach. Eine Komponente benötigt nur wenige Dinge:
Ein Repository, in dem sie gespeichert wird.
Eine CI/CD-Konfigurationsdatei, die die Komponente veröffentlicht.
Eine README-Datei mit einer grundlegenden Beschreibung der Funktion der Komponente.
Eine kurze Projektbeschreibung im Repository.
Außerdem muss in den Repository-Einstellungen die Option „CI/CD Catalog project“ aktiviert sein.
Mit all dem im Hinterkopf erstellen wir unsere erste Komponente! Beginnen wir mit dem Einfachsten: dem CI/CD-Skript, das unsere Komponente veröffentlicht.
stages:
- release
release:
stage: release
rules:
- if: $CI_COMMIT_TAG
image: registry.gitlab.com/gitlab-org/release-cli:v0.18.0
script:
- echo "Creating release
release:
tag_name: $CI_COMMIT_TAG
description: './README.md
Diese Pipeline-Konfiguration sucht lediglich nach Tags. Wird eines veröffentlicht, erstellt sie ein Release mit der README als Beschreibung. Mehr braucht ihr wirklich nicht. Darauf aufbauend erstellt GitLab selbstständig weitere Dokumentation und übernimmt die Veröffentlichung.
In der Datei README.md können wir nun einfach eine kurze Beschreibung wie diese hinzufügen:
„Komponente, die ein .NET-9-Projekt in der NuGET-Registry veröffentlicht.“
Da wir nun die meisten Voraussetzungen erfüllt haben, wandeln wir die eigentliche Pipeline um. Dazu erstellen wir im Repository ein Verzeichnis namens „templates“ und legen darin eine neue Datei namens „publish.yml“ an. Hier geschieht die eigentliche Magie: Komponenten ermöglichen es euch, vor der Vorlage selbst eine Spezifikation zu definieren. So könnt ihr Beschreibungen und die erwarteten Eingaben der Vorlage festlegen. GitLab verwendet diese Eingaben und ihre Beschreibungen, um eine grundlegende Dokumentation der jeweiligen Vorlage zu erstellen.
In unserem Fall ist das beispielsweise recht einfach und umfasst nur zwei Eingaben: Möchten wir die Veröffentlichung erzwingen oder die Stage der Pipeline überschreiben? Das könnte etwa so aussehen:
spec:
inputs:
stage:
default: publish
description: 'Defines which build stage will be used.
force-publish:
default: false
description: 'Do you want to force the publishing of the NuGET package.
Im letzten Schritt passen wir unsere Vorlage an, damit sie diese Eingaben statt Umgebungsvariablen verwendet. Auch das ist sehr einfach und sieht etwa so aus:
publish-nuget-package": stage: $[[ inputs.stage ]] image: mcr.microsoft.com/dotnet/sdk:9.0 only: - tags - $[[ inputs.force-publish ]] == "true" script: - dotnet pack -c release - dotnet nuget add source
${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text - dotnet nuget push "**/bin/Release/*.nupkg" --source gitlab
Beachtet: Statt $FORCE_PUBLISH verwenden wir nun $[[ input.force-publish ]].
Anschließend können wir beides zu unserer vollständigen Vorlage zusammenführen, die sowohl die Spezifikation als auch die Pipeline enthält:
spec:
inputs:
stage:
default: publish
description: 'Defines which build stage will be used.
force-publish:
default: false
description: 'Do you want to force the publishing of the NuGET package.
---
publish-nuget-package": stage: $[[ inputs.stage ]] image: mcr.microsoft.com/dotnet/sdk:9.0 only: - tags - $[[ inputs.force-publish ]] == "true" script: - dotnet pack -c release - dotnet nuget add source
${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text - dotnet nuget push "**/bin/Release/*.nupkg" --source gitlab
Voilà! Ihr habt jetzt eine funktionierende GitLab-Komponente. Denkt daran, sie mindestens einmal zu taggen, damit eine nutzbare Version wie 1.1.0 erstellt wird.
Sobald der Workflow der Tag-Pipeline abgeschlossen ist, könnt ihr oben im Repository auf die blaue Schaltfläche „CI/CD Catalog“ klicken, um die Katalogseite aufzurufen. Dort findet ihr eine Möglichkeit, den Workflow in einer bestimmten Version einzubinden, sowie automatisch generierte Dokumentation zu seinen Optionen.
Um diese Komponente zu verwenden, müsst ihr sie beispielsweise nur in eure CI-Datei einbinden:
include:
- component: $CI_SERVER_FQDN/components/example-comp/publish@1.0.0
inputs:
stage: deploy
force-publish: false
Hinweis: Beachtet, wie die Variablen über die Eigenschaft „input“ übergeben werden.
Abschließende Gedanken
Letztlich sind GitLab Components eine einfache Möglichkeit, auffindbare und dokumentierte CI/CD-Vorlagen auf eurer GitLab-Instanz bereitzustellen. Sie lassen sich nicht nur einfach von Grund auf erstellen, sondern können auch auf bestehenden Pipelines basieren.
Alle veröffentlichten Components findet ihr auf eurer GitLab-Instanz in der Ansicht „Explore“ und anschließend „CI/CD Catalog“.
- Software development
- DevOps
- GitLab
Subscribe to our newsletter
Related blogs
