Forgejo Pipelines · Workshop Lektion 2 / Jobs & needs

Jobs, Reihenfolge & needs

Vom Einzeljob zur Kette: Ordnung herstellen – ganz ohne stages.

Warum das zählt
Eine echte Pipeline hat mehrere Jobs, von denen manche gleichzeitig laufen dürfen und manche aufeinander warten müssen. In Forgejo steuerst du das allein über needs – das ist der Kern jeder mehrstufigen Pipeline und eine der ersten Forgejo-Besonderheiten im Workshop.

Kurzer Rückruf

Erst aus dem Kopf, dann weiterlesen:

Wie laufen mehrere Jobs eines Workflows standardmässig?

Parallel ist der Normalfall

Schreibst du zwei Jobs ohne weitere Angaben, starten beide gleichzeitig. Das ist schnell, aber nicht immer gewünscht – oft soll test erst laufen, wenn lint grün ist. Dafür gibt es genau ein Werkzeug:

needs statt stages GitLab ordnet Jobs in stages: (feste Phasen). Forgejo kennt das nicht. Stattdessen sagt jeder Job mit needs: [andererJob], auf wen er wartet. So entsteht ein Graph (DAG) statt starrer Phasen – flexibler und meist schneller.

Eine Kette mit Verzweigung

.forgejo/workflows/ci.yaml
on: [push]
jobs:
  lint:
    runs-on: docker
    container: python:3.12-slim
    steps:
      - uses: actions/checkout@v4
      - run: pip install ruff && ruff check app tests

  test:
    runs-on: docker
    container: python:3.12-slim
    needs: [lint]            # wartet auf lint
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt && pytest -q

  build:
    runs-on: docker
    needs: [test]            # wartet auf test
    steps:
      - run: echo "Image bauen … (Lektion 8)"

Ergebnis: linttestbuild, eine saubere Kette. Kämen zwei Jobs mit demselben needs: [lint], liefen sie nach lint parallel – ein „Fan-out". Ein späterer Job mit needs: [a, b] wartet auf beide – ein „Fan-in".

zuerst

lint

dann

test

zuletzt

build
Der Graph entsteht allein aus den needs-Angaben, nicht aus der Reihenfolge im File.

Zwei Stolperfallen, die jeden treffen

Jeder Job startet bei null Jobs teilen sich kein Dateisystem. Jeder läuft frisch (oft auf einem anderen Runner). Deshalb steht in fast jedem Job wieder ein actions/checkout. Dateien von Job zu Job reicht man über Artifacts – das ist Lektion 3.
needs ≠ Datei-Übergabe needs regelt nur die Reihenfolge (und macht Job-outputs verfügbar). Es kopiert keine Build-Ergebnisse. Wer das verwechselt, sucht lange nach „verlorenen" Dateien.

Parallelen: GitLab CI ↔ Forgejo Actions

GitLab CI

Phasen via stages:-Liste

Job nennt sein stage:

needs: nur zum Beschleunigen (DAG)

Forgejo Actions

Keine Phasen

Job nennt needs: [...]

needs: ist der Ordnungs-Mechanismus

Übungen für Teilnehmende

Übung 1 · Vorhersagen

Frage: Du fügst einen Job typecheck mit needs: [lint] hinzu (neben test). Laufen test und typecheck nacheinander oder gleichzeitig?

Lösung anzeigen

Gleichzeitig – beide hängen nur an lint und sind voneinander unabhängig (Fan-out). build würde mit needs: [test, typecheck] auf beide warten.

Übung 2 · Selbst schreiben

Aufgabe: Ergänze die Pipeline um einen Job security (Image python:3.12-slim), der pip install pip-audit && pip-audit ausführt und parallel zu test nach dem Linten läuft.

Tipp: Es geht nur um das richtige needs.

Lösung anzeigen
  security:
    runs-on: docker
    container: python:3.12-slim
    needs: [lint]          # gleiches needs wie test -> parallel
    steps:
      - uses: actions/checkout@v4
      - run: pip install pip-audit && pip-audit

Kurz prüfen (aus dem Kopf)

Was bestimmt, ob Job B nach Job A läuft?

Warum braucht fast jeder Job ein eigenes checkout?

Primärquelle zum Lesen Forgejo Docs – Reference, Abschnitt jobs.<id>.needs. Schau dir an, wie needs zusätzlich Job-outputs verfügbar macht – das nutzen wir ab Lektion 8.
Ich bin dein Teacher. Unklar, wie aus needs ein Graph wird oder warum Jobs isoliert laufen? Frag im Chat – ich zeichne dir den DAG gern an deinem Beispiel auf.
← Lektion 1 · Was sind Forgejo Actions? Lektion 3 · Artifacts & Cache →