GitLab Pipelines · Workshop Lektion 12 / include & Components

include & CI/CD Components

Pipelines aufteilen, teilen und wiederverwenden – über Projektgrenzen hinweg.

Warum das zählt
Eine einzige riesige .gitlab-ci.yml wird unübersichtlich, und dieselbe Test-Logik in zehn Repos zu kopieren ist Wartungs-Gift. include teilt Pipelines auf; CI/CD Components machen daraus versionierte, geteilte Bausteine. So skaliert dein Workshop-Wissen auf viele Projekte.

Kurzer Rückruf

Wann startet ein Job mit needs: []?

Vier Wege, Konfiguration einzubinden

include: localDatei aus demselben Repo
include: projectDatei aus einem anderen GitLab-Projekt
include: templateMitgelieferte GitLab-Vorlage
include: remoteDatei über eine HTTPS-URL
include: componentversionierter, parametrisierbarer Baustein

Die eigene Pipeline aufteilen (local)

# .gitlab-ci.yml
include:
  - local: .gitlab/ci/test.yml
  - local: .gitlab/ci/deploy.yml

stages: [test, deploy]

Die Jobs leben in thematischen Dateien; die Haupt-.gitlab-ci.yml bleibt schlank und lesbar.

CI/CD Components: geteilte, versionierte Bausteine

Ein Component ist eine wiederverwendbare Pipeline-Einheit mit Inputs und einer Version, veröffentlicht im CI/CD-Katalog. Du bindest ihn so ein: 

include:
  - component: $CI_SERVER_FQDN/puzzle/ci-components/python-test@1.2.0
    inputs:
      python_version: "3.13"
      stage: test
Dein Win Du kannst eine geprüfte Test-/Build-Logik einmal schreiben und in beliebig vielen Projekten versioniert wiederverwenden – statt YAML zu kopieren.

Besonderheiten & Stolperfallen

Immer eine Version pinnen @~latest oder ein Branch kann sich jederzeit ändern und deine Pipeline über Nacht brechen. Pinne eine feste Version (@1.2.0 oder einen SHA) und aktualisiere bewusst.
Inputs sind typisiert und sicherer als globale Variablen Component-Inputs (spec: inputs:) haben Typen und Defaults und werden zur Pipeline-Erstellung ausgewertet ($[[ inputs.x ]]) – nicht zur Laufzeit. Klarer Vertrag statt loser Variablen.
Reihenfolge & Überschreiben Eingebundene Jobs lassen sich lokal überschreiben: Ein Job mit gleichem Namen in deiner .gitlab-ci.yml ergänzt/überschreibt den eingebundenen. So passt du einen Component punktuell an.
include lädt zur Pipeline-Erstellung Alle include-Quellen werden eingelesen, bevor die Pipeline startet. Ist eine Quelle nicht erreichbar oder fehlerhaft, entsteht gar keine Pipeline – nicht erst ein roter Job.

Übung für Teilnehmende

Übung 1 · Aufteilen

Aufgabe: Lagere alle Test-Jobs in .gitlab/ci/test.yml aus und binde sie in der Haupt­datei ein.

Lösung anzeigen 
include:
  - local: .gitlab/ci/test.yml

Die Jobs ziehen in die ausgelagerte Datei; die Haupt-.gitlab-ci.yml verweist nur noch.

Übung 2 · Risiko erkennen

Frage: Ein Kollege bindet einen Component mit @main ein. Welches Risiko – und die bessere Wahl?

Lösung anzeigen

@main ändert sich bei jedem Commit im Component-Repo – die Pipeline kann ohne eigenes Zutun brechen. Besser: eine feste Version wie @1.2.0 pinnen.

Übung 3 · Einordnen

Frage: Du willst die offizielle SAST-Vorlage von GitLab nutzen. Welcher include-Typ?

Lösung anzeigen

include: template (z. B. Security/SAST.gitlab-ci.yml) – die mitgelieferten GitLab-Vorlagen.

Kurz prüfen (aus dem Kopf)

Was zeichnet einen CI/CD Component aus?

Warum eine feste Component-Version pinnen?

Primärquelle zum Lesen GitLab Docs – CI/CD Components und include-Beispiele.
Frag deinen Teacher. Willst du einen eigenen Component für die Tasks-API bauen? Sag Bescheid, wir machen das zusammen.
← Lektion 11 Lektion 13 · Besonderheiten →