GitLab Pipelines · Workshop Lektion 11 / needs & DAG

needs – die Pipeline beschleunigen

Jobs starten, sobald ihre Voraussetzung fertig ist – nicht der ganze Stage.

Warum das zählt
Stages sind einfach, aber stur: Jeder Stage wartet auf den komplett vorigen. Oft unnötig. Mit needs baust du einen gerichteten Abhängigkeitsgraphen (DAG) – Jobs starten früher, die Pipeline wird spürbar schneller. Genau das, was grosse Pipelines erträglich macht.

Kurzer Rückruf

Was braucht ein GitLab-Pages-Deploy?

Das Problem mit reinen Stages

Angenommen: lint → test → build → deploy. Der build-Job hängt eigentlich nur von test ab, nicht von lint. Trotzdem wartet er, bis der ganze test-Stage (inkl. langsamem mypy) fertig ist. needs durchbricht das.

Ohne needs

streng Stage für Stage
build wartet auf ALLES in test
vs.

Mit needs (DAG)

build startet nach pytest
mypy läuft daneben weiter
Mit needs richtet sich der Start nach echten Abhängigkeiten – nicht nach der Stage-Grenze.

Die .gitlab-ci.yml

pytest:
  stage: test
  script: [pytest -q]

mypy:
  stage: test
  script: [mypy app]

build:
  stage: build
  needs: ["pytest"]      # startet, sobald pytest grün ist – ignoriert mypy
  script: [python -m build]

needs + Artifacts

Standardmässig lädt ein Job die Artifacts aller vorigen Stages. Mit needs bekommt er nur die Artifacts der genannten Jobs. Das ist meist gewünscht – aber eine bewusste Änderung: 

deploy:
  stage: deploy
  needs:
    - job: build
      artifacts: true   # Wheel aus build übernehmen
  script: [./deploy.sh]
Dein Win Du steuerst den Pipeline-Fluss jetzt nach echten Abhängigkeiten – die schnellste sinnvolle Reihenfolge.

Besonderheiten & Stolperfallen

needs kann nur „nach hinten" zeigen Ein Job darf nur Jobs benötigen, die vor ihm liegen (früherer oder gleicher Stage). Ein Verweis auf einen späteren Stage ist ein Konfigurationsfehler.
Leeres needs: [] = sofort starten needs: [] löst einen Job aus den Stages: Er startet ganz am Anfang, parallel zu allem. Praktisch für einen schnellen Vorab-Check, der nichts braucht.
Weniger Artifacts als gedacht Sobald ein Job needs nutzt, bekommt er nur noch die Artifacts der genannten Jobs – nicht mehr automatisch alle vorigen. Fehlt plötzlich eine Datei, ist das oft die Ursache.
DAG macht den Graphen sichtbar In der Pipeline-Ansicht kannst du auf „Job dependencies / Needs" umschalten und den Graphen sehen – sehr hilfreich, um im Workshop zu zeigen, warum ein Job wann startet.

Übung für Teilnehmende

Übung 1 · Beschleunigen

Aufgabe: build soll starten, sobald pytest fertig ist, ohne auf den langsamen mypy (gleicher Stage) zu warten.

Lösung anzeigen 
build:
  stage: build
  needs: ["pytest"]

build hängt jetzt nur an pytest; mypy läuft unabhängig weiter.

Übung 2 · Vorhersagen

Frage: build hat needs: ["pytest"]. mypy schlägt fehl, pytest ist grün. Läuft build?

Lösung anzeigen

Ja. build braucht nur pytest – der ist grün. Der rote mypy lässt aber die Gesamtpipeline rot werden. (Mit allow_failure liesse sich das entkoppeln.)

Übung 3 · Sofort-Job

Frage: Du willst einen secret-scan, der unabhängig von allem ganz früh startet. Wie?

Lösung anzeigen

needs: [] (leer). Damit ignoriert der Job die Stage-Reihenfolge und startet sofort parallel zum Pipeline-Beginn.

Kurz prüfen (aus dem Kopf)

Was bewirkt needs an einem Job?

Was ändert needs an den Artifacts?

Primärquelle zum Lesen GitLab Docs – needs und Directed Acyclic Graph.
Frag deinen Teacher. Unklar, wie sich needs und Stages mischen lassen? Frag im Chat.
← Lektion 10 Lektion 12 · include & Components →