GitLab Pipelines · Workshop Lektion 1 / Einführung

Was ist eine Pipeline?

Dein erstes .gitlab-ci.yml – eine echte App testet sich selbst.

Warum das zählt
Am Ende dieser Lektion verstehst du das Vokabular (Pipeline, Stage, Job, Runner) und kannst eine erste lauffähige Pipeline lesen und schreiben. Das ist das Fundament, auf dem jede weitere Lektion – und dein Workshop – aufbaut.

Unser durchgehendes Beispiel

Statt „Hello World" begleitet uns durch den ganzen Kurs eine kleine, echte App: eine FastAPI-„Tasks"-API in Python – ein Service, der Aufgaben verwaltet. Das Repo enthält ungefähr das hier:

tasks-api/
├── app/
│   └── main.py          # die FastAPI-App
├── tests/
│   └── test_main.py     # pytest-Tests
├── requirements.txt
└── .gitlab-ci.yml       # ← darum geht es

Jedes Mal, wenn jemand Code pusht, soll GitLab automatisch prüfen: Ist der Code sauber formatiert? Laufen die Tests durch? Genau das ist die Aufgabe einer Pipeline.

Die vier Begriffe

Eine Pipeline besteht aus vier Bausteinen. Mehr brauchst du fürs Erste nicht:

Bildlich: die Pipeline ist das Fliessband, Stages sind die Stationen in fester Reihenfolge, und Jobs sind die Arbeiter, die an einer Station gleichzeitig anpacken.

lint

ruff

test

pytest
Unsere erste Pipeline: zwei Stages, je ein Job. test startet erst, wenn lint grün ist.

Die erste .gitlab-ci.yml

Die ganze Pipeline lebt in einer einzigen YAML-Datei im Wurzelverzeichnis des Repos. Hier ist sie – Zeile für Zeile danach erklärt:

stages:
  - lint
  - test

default:
  image: python:3.12-slim

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

pytest:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest -q

Was hier passiert

Dein erster Win Du kannst diese Datei jetzt lesen und in Worten erklären, was beim nächsten Push passiert: GitLab startet eine Pipeline, führt ruff aus, und nur wenn das klappt, danach pytest.

Besonderheiten & Stolperfallen

Einrückung mit Leerzeichen YAML ist tab-feindlich. Nutze immer Leerzeichen (2 pro Ebene), niemals Tabs – sonst bricht die Pipeline mit einem Syntaxfehler, der schwer zu finden ist.
Dateiname & Ort Die Datei muss exakt .gitlab-ci.yml heissen (mit führendem Punkt) und im Repo-Wurzelverzeichnis liegen. gitlab-ci.yaml oder ein Unterordner werden ignoriert.
Ohne Runner läuft nichts Jobs brauchen einen Runner, der sie ausführt. Auf GitLab.com sind shared Runner aktiv; auf einer self-hosted-Instanz (wie bei Puzzle) muss ein Runner registriert und per tags erreichbar sein – sonst bleibt der Job „pending" hängen.
Reservierte Namen Job-Namen sind frei – aber ein paar Wörter sind reserviert (u. a. stages, default, variables, workflow, include). Die kannst du nicht als Job-Namen verwenden.

Kurz prüfen (aus dem Kopf)

Nicht spicken – Abrufen aus dem Gedächtnis ist genau die Übung, die hängen bleibt.

In welcher Beziehung stehen Stages und Jobs zeitlich zueinander?

Welches Keyword ist in jedem Job zwingend erforderlich?

Was passiert, wenn der lint-Stage rot wird?

Primärquelle zum Lesen GitLab Docs – CI/CD Pipelines. Die maßgebliche Einführung. Lies den Abschnitt „Pipelines" und überflieg das erste Beispiel – du wirst die Begriffe jetzt wiedererkennen.
Ich bin dein Teacher. Wenn etwas unklar ist – warum ein Stage wartet, wie ein Runner ausgewählt wird, wie das FastAPI-Beispiel genau aussieht – frag einfach im Chat nach. Genau dafür bin ich da.
Glossar & Keyword-Referenz Lektion 2 · Stages & Reihenfolge →
Als Nächstes: Lektion 2 – Stages & Job-Reihenfolge (build → test → deploy, parallele Jobs)