Förenkla din DevOps-vardag med GitLab Components

Vad är en komponent?

GitLab Components förenklar allt detta. Komponenter introducerades i GitLab 17.0 och ger dig en katalog med CI/CD-komponenter som enkelt finns tillgängliga för användning i valfritt repository i din organisation.

”Men vänta!” säger du, ”Vi har ju redan skrivit alla dessa CI/CD-pipelines. Varför skulle vi lägga tid på att skriva om allt i ett nytt system? Det kräver tid och arbete, och vi måste dokumentera allt igen.”

Det är här magin med GitLab Components kommer in: Du behöver bara göra minimala ändringar i dina befintliga CI/CD-pipelines.

Din första komponent

Låt oss titta på följande CI/CD-mall: Säg att du vill bygga en .NET 9-applikation och sedan publicera binärfilerna i det interna GitLab NuGET-repositoryt:

Kort sagt: om en tagg publiceras eller variabeln FORCE_PUBLISH sätts till ”true”, kommer pipelinen att paketera projektet, lägga till GitLab NuGET-repositoryt och skicka det paketerade innehållet dit.

Det är mycket enkelt att konvertera den här pipelinen till en komponent. En komponent behöver bara några få saker:

1. Ett repository där den ska finnas.

2. En CI/CD-konfigurationsfil som publicerar komponenten.

3. En README-fil med en grundläggande beskrivning av vad komponenten gör.

4. En grundläggande projektbeskrivning i repositoryt.

5. Till sist behöver du aktivera ”CI/CD Catalog project” i repositoryts inställningar.

Med detta på plats kan vi skapa vår första komponent! Vi börjar med det enklaste: CI/CD-skriptet som publicerar komponenten.

Den här pipelinekonfigurationen letar bara efter taggar. När en tagg publiceras skapar den en release med README-filen som beskrivning. Det är egentligen allt som behövs. GitLab hanterar sedan själv genereringen av ytterligare dokumentation och publiceringen.

I README.md-filen kan vi sedan lägga till en enkel beskrivning, till exempel:

”Komponent som publicerar ett .NET 9-projekt till NuGET-registret.”

Nu när vi har uppfyllt de flesta förutsättningarna kan vi konvertera själva pipelinen. Skapa en katalog med namnet ”templates” i repositoryt och lägg till en ny fil med namnet ”publish.yml”. Det är här den verkliga magin sker. Med komponenter kan du ange en specifikation före själva mallen, där du kan lägga till beskrivningar och definiera vilka indata mallen förväntar sig. GitLab använder sedan dessa indata och deras beskrivningar för att generera grundläggande dokumentation för mallen.

I vårt fall blir det till exempel ganska enkelt, med bara två indata: Vill vi tvinga fram publicering eller åsidosätta pipelinens stage? Det kan se ut ungefär så här:

Det sista steget är att ändra vår mall så att den använder dessa indata i stället för miljövariabler. Det är också mycket enkelt och kan se ut ungefär så här:

Observera att vi i stället för att använda $FORCE_PUBLISH använder $[[ input.force-publish ]].

Vi kan sedan kombinera de två för att få vår kompletta mall, som innehåller både spec:en och själva pipelinen:

Voilà! Du har nu en fungerande GitLab Component. Kom ihåg att tagga den minst en gång för att skapa en användbar version, till exempel 1.1.0.

När taggpipelineflödet är klart kan du klicka på den blå CI/CD Catalog-knappen högst upp i repositoryt för att se katalogsidan. Där hittar du ett sätt att inkludera arbetsflödet för den specifika versionen samt automatiskt genererad dokumentation för dess alternativ.

För att använda den här komponenten behöver du bara inkludera den i din CI-fil:

Obs: Lägg märke till hur variablerna skickas via egenskapen ”input”.

Avslutande tankar

I slutändan är GitLab Components ett enkelt sätt att ha CI/CD-mallar som är lätta att hitta och väldokumenterade i din GitLab-instans. De är inte bara enkla att skapa från grunden, utan kan också baseras på befintliga pipelines.

Du hittar alla publicerade komponenter i din GitLab-instans under ”Explore” och sedan ”CI/CD Catalog”.