GitLab Pipelines · Workshop Lektion 2 / Stages

Stages & Job-Reihenfolge

Vom Zweischritt zur echten Kette: build → test → deploy mit parallelen Jobs.

Warum das zählt
Eine reale Pipeline hat mehr als zwei Schritte und führt manches gleichzeitig aus, um Zeit zu sparen. Wer steuern kann, was nacheinander und was parallel läuft, hat das Grundgerüst jeder CI/CD-Pipeline in der Hand – und damit den Kern, den du im Workshop vermittelst.

Kurzer Rückruf

Erst aus dem Kopf, dann weiterlesen – das festigt Lektion 1:

Wie laufen mehrere Jobs im selben Stage?

Die Idee: Stationen am Fliessband

Unsere Tasks-API bekommt jetzt vier Stationen. Manche Stationen haben mehrere Arbeiter, die gleichzeitig anpacken:

lint

ruff
→

test

pytest
mypy
→

build

package
→

deploy

deploy
pytest und mypy laufen gleichzeitig. Erst wenn beide grün sind, beginnt build.

Die .gitlab-ci.yml

stages:
  - lint
  - test
  - build
  - deploy

default:
  image: python:3.12-slim

ruff:
  stage: lint
  script:
    - pip install ruff && ruff check app tests

pytest:            # läuft parallel zu mypy
  stage: test
  script:
    - pip install -r requirements.txt && pytest -q

mypy:              # läuft parallel zu pytest
  stage: test
  script:
    - pip install mypy && mypy app

package:
  stage: build
  script:
    - pip install build && python -m build

deploy:
  stage: deploy
  script:
    - echo "Deploy nach staging … (echtes Deploy folgt in Lektion 9)"

Zwei Jobs (pytest, mypy) teilen sich den Stage test – also laufen sie gleichzeitig. Die Reihenfolge der Stages in der stages:-Liste bestimmt den Ablauf der Stationen.

Dein Win Du steuerst jetzt zwei Dinge unabhängig: die Reihenfolge (über die Position in stages:) und die Parallelität (mehrere Jobs in denselben Stage legen).

Besonderheiten & Stolperfallen

Es gibt vordefinierte Stages Wenn du stages: ganz weglässt, nutzt GitLab automatisch: .pre → build → test → deploy → .post. Ein Job ohne stage:-Angabe landet standardmässig in test.
.pre und .post Die Spezial-Stages .pre (immer ganz zuerst) und .post (immer ganz zuletzt) brauchst du nicht in stages: aufzulisten – sie sind immer verfügbar. Praktisch z. B. für einen globalen Setup- oder Aufräum-Job.
Reihenfolge innerhalb eines Stages ist nicht garantiert pytest startet nicht zwingend vor mypy. Verlass dich nie auf die Start-Reihenfolge paralleler Jobs – sie dürfen nicht voneinander abhängen. (Echte Abhängigkeiten kommen in Lektion 10 mit needs.)
Leere Stages verschwinden Ein Stage, in dem kein einziger Job läuft, wird einfach übersprungen – kein Fehler, aber er taucht in der Pipeline-Ansicht nicht auf. Gut zu wissen, wenn du dich wunderst, wo ein Stage hin ist.

Übung für Teilnehmende

Übung 1 · Lesen

Frage: Du fügst dem Stage build einen zweiten Job docs hinzu. Laufen package und docs nacheinander oder gleichzeitig?

Lösung anzeigen

Gleichzeitig – sie sind im selben Stage build. deploy startet erst, wenn beide fertig und grün sind.

Übung 2 · Selbst schreiben

Aufgabe: Ergänze die Pipeline um einen neuen Stage security zwischen test und build, mit einem Job pip-audit, der pip install pip-audit && pip-audit ausführt.

Tipp: Zwei Stellen ändern – die stages:-Liste und einen neuen Job-Block.

Lösung anzeigen 
stages:
  - lint
  - test
    - security        # neu, an der richtigen Position
  - build
  - deploy

# … bestehende Jobs …

pip-audit:
  stage: security
  script:
    - pip install pip-audit && pip-audit

Die Position in stages: bestimmt, wann der Stage läuft – nicht die Position des Job-Blocks weiter unten.

Übung 3 · Vorhersagen

Frage: mypy schlägt fehl, pytest ist grün. Welche der Stages build und deploy laufen noch?

Lösung anzeigen

Keiner von beiden. Da mypy im Stage test rot ist, gilt der ganze Stage als fehlgeschlagen – build und deploy starten nicht. (Wie man einen Job trotzdem „nicht blockierend" macht, zeigt allow_failure später.)

Kurz prüfen (aus dem Kopf)

Was bestimmt, in welcher Reihenfolge Stages ablaufen?

Welchen Stage bekommt ein Job ganz ohne stage:?

Primärquelle zum Lesen GitLab Docs – stages & stage. Schau dir die Abschnitte zu vordefinierten Stages und .pre/.post an.
Frag deinen Teacher. Unklar, warum parallele Jobs Runner-Kapazität brauchen, oder wie sich ein roter Job genau auf die Pipeline auswirkt? Schreib mir im Chat.
← Lektion 1 · Was ist eine Pipeline? Glossar →
Als Nächstes: Lektion 3 – Artifacts & Cache (Coverage-Report weitergeben, Dependencies cachen)