needsVom Einzeljob zur Kette: Ordnung herstellen – ganz ohne stages.
needs – das ist
der Kern jeder mehrstufigen Pipeline und eine der ersten Forgejo-Besonderheiten im Workshop.
Erst aus dem Kopf, dann weiterlesen:
Wie laufen mehrere Jobs eines Workflows standardmässig?
Jobs sind voneinander unabhängig und laufen parallel (genug Runner-Kapazität vorausgesetzt).
Reihenfolge entsteht erst durch needs.
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:
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.
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: lint → test → build, 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".
needs-Angaben, nicht aus der Reihenfolge im File.actions/checkout. Dateien von
Job zu Job reicht man über Artifacts – das ist Lektion 3.
needs regelt nur die Reihenfolge (und macht Job-outputs
verfügbar). Es kopiert keine Build-Ergebnisse. Wer das verwechselt, sucht lange nach „verlorenen"
Dateien.
Phasen via stages:-Liste
Job nennt sein stage:
needs: nur zum Beschleunigen (DAG)
Keine Phasen
Job nennt needs: [...]
needs: ist der Ordnungs-Mechanismus
Frage: Du fügst einen Job typecheck mit needs: [lint]
hinzu (neben test). Laufen test und typecheck nacheinander
oder gleichzeitig?
Gleichzeitig – beide hängen nur an lint und sind voneinander
unabhängig (Fan-out). build würde mit needs: [test, typecheck] auf
beide warten.
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.
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
Was bestimmt, ob Job B nach Job A läuft?
Allein needs erzeugt die Reihenfolge. File-Position ist egal, und stages
gibt es in Forgejo nicht.
Warum braucht fast jeder Job ein eigenes checkout?
Jeder Job startet frisch, evtl. auf einem anderen Runner. Ohne erneutes checkout
liegt der Code nicht im Workspace.
jobs.<id>.needs. Schau dir an, wie needs zusätzlich
Job-outputs verfügbar macht – das nutzen wir ab Lektion 8.
needs ein Graph wird oder warum Jobs
isoliert laufen? Frag im Chat – ich zeichne dir den DAG gern an deinem Beispiel auf.