GitLab Pipelines · Workshop Lektion 4 / Variables & DRY

Variables & DRY-Pipelines

variables, before_script, default, extends – Wiederholung vermeiden.

Warum das zählt
Bisher wiederholt sich in jedem Job pip install …. Sobald eine Pipeline wächst, wird das unwartbar. Variablen und Vererbung machen die .gitlab-ci.yml kurz, lesbar und änderbar an einer Stelle – die Grundlage jeder professionellen Pipeline.

Kurzer Rückruf

Welches Keyword gibt ein Ergebnis an spätere Jobs weiter?

Vier Werkzeuge gegen Wiederholung

1 · variables – Werte benennen

variables:                 # global: gilt für alle Jobs
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"
  APP_DIR: "app"

ruff:
  stage: lint
  variables:               # job-lokal: überschreibt global
    RUFF_FLAGS: "--select E,F"
  script:
    - ruff check $APP_DIR $RUFF_FLAGS

Variablen werden mit $NAME verwendet. Job-lokale Variablen gewinnen gegen globale.

2 · default – gemeinsame Job-Einstellungen

default:
  image: python:3.12-slim
  before_script:          # läuft vor JEDEM script
    - python --version
    - pip install -r requirements.txt

before_script in default spart das wiederholte Setup. Jeder Job führt es automatisch vor seinem eigenen script aus.

3 · extends – Job-Vorlagen erben

.python-job:            # „hidden job" (Punkt-Präfix): läuft nie selbst
  image: python:3.12-slim
  before_script:
    - pip install -r requirements.txt

pytest:
  extends: .python-job   # erbt image + before_script
  stage: test
  script:
    - pytest -q

mypy:
  extends: .python-job
  stage: test
  script:
    - pip install mypy && mypy app
Dein Win Das Setup steht jetzt an einer Stelle. Python-Version wechseln? Eine Zeile in .python-job – nicht in fünf Jobs.

Besonderheiten & Stolperfallen

Hidden Jobs (Punkt-Präfix) Ein Job, dessen Name mit . beginnt (.python-job), wird nie ausgeführt – er dient nur als Vorlage zum extends. Praktisch, um Bausteine zu definieren.
Vordefinierte Variablen GitLab liefert viele Variablen frei Haus: CI_COMMIT_BRANCH, CI_PROJECT_DIR, CI_PIPELINE_SOURCE, CI_REGISTRY_IMAGE … Du brauchst sie in fast jeder späteren Lektion. (Referenz: Variablen-Spickzettel.)
Secrets gehören NICHT ins YAML Passwörter und Tokens niemals in variables: im Repo schreiben – das ist Klartext in der Versionsgeschichte. Stattdessen CI/CD-Variablen in den Projekt-Einstellungen anlegen und dort als masked / protected markieren. Mehr dazu in Lektion 12.
before_script überschreibt, nicht ergänzt Definiert ein Job ein eigenes before_script, ersetzt es das aus default – es wird nicht angehängt. Überraschend, wenn das globale Setup plötzlich fehlt.

Übung für Teilnehmende

Übung 1 · Refactoring

Aufgabe: Drei Jobs beginnen alle mit pip install -r requirements.txt. Zieh das in einen Hidden Job .deps und nutze extends.

Lösung anzeigen 
.deps:
  before_script:
    - pip install -r requirements.txt

pytest:
  extends: .deps
  stage: test
  script: [pytest -q]
Übung 2 · Vorhersagen

Frage: Global gilt GREETING: "hallo", im Job steht GREETING: "ciao". Was gibt echo $GREETING im Job aus?

Lösung anzeigen

ciao. Job-lokale Variablen überschreiben gleichnamige globale.

Übung 3 · Sicherheit

Frage: Wohin gehört ein Deploy-Token DEPLOY_KEY – und warum nicht ins File?

Lösung anzeigen

In die CI/CD-Variablen der Projekt-Einstellungen, als masked und protected. Im YAML wäre es Klartext in der Git-Historie – ein dauerhaftes Leck, selbst nach späterem Entfernen.

Kurz prüfen (aus dem Kopf)

Wozu dient ein Job mit Punkt-Präfix wie .base?

Wo gehören Passwörter und Tokens hin?

Primärquelle zum Lesen GitLab Docs – CI/CD variables. Vordefinierte Variablen, masked/protected, Reihenfolge der Überschreibung.
Frag deinen Teacher. Unklar, wie extends mit mehreren Vorlagen mischt? Schreib mir.
← Lektion 3 Lektion 5 · Testberichte darstellen →