GitLab Pipelines · Workshop Lektion 6 / rules & workflow

rules & workflow

Wann läuft was? Jobs und ganze Pipelines gezielt steuern.

Warum das zählt
Nicht jeder Job soll immer laufen: Tests bei jedem Push, Deploy nur auf main, manche Jobs nur im Merge Request. rules ist das Steuerpult dafür – und der Punkt, an dem aus „läuft halt alles" eine durchdachte Pipeline wird.

Kurzer Rückruf

Wohin gehören geheime Tokens?

Das alte und das neue Werkzeug

Früher steuerte man Jobs mit only/except. Heute ist rules der Standard – mächtiger und besser lesbar. Mische die beiden nie im selben Job.

Eine rules-Liste wird von oben nach unten ausgewertet. Die erste zutreffende Regel gewinnt und bestimmt, ob (und wie) der Job läuft. Trifft keine zu, läuft der Job nicht.

Bedingungen mit rules: if

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    # nur auf dem Default-Branch (main) automatisch deployen
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    # sonst: gar nicht
    - when: never

Die wichtigsten vordefinierten Variablen für Regeln:

CI_PIPELINE_SOURCEpush, merge_request_event, schedule, web …
CI_COMMIT_BRANCHName des Branches (bei Branch-Pipelines)
CI_DEFAULT_BRANCHDer Default-Branch des Projekts (meist main)
CI_COMMIT_TAGgesetzt, wenn die Pipeline für einen Tag läuft

Weitere Regel-Typen

rules:
  # nur wenn sich App-Code geändert hat
  - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    changes:
      - app/**/*
  # nur wenn eine Datei existiert
  - exists:
      - Dockerfile

Die ganze Pipeline steuern: workflow

rules entscheidet pro Job. workflow: rules entscheidet, ob die Pipeline überhaupt entsteht – ideal gegen doppelte Pipelines: 

workflow:
  rules:
    # keine Pipeline für Commits mit „-draft" im Titel
    - if: $CI_COMMIT_TITLE =~ /-draft$/
      when: never
    # Pipeline für Merge Requests …
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    # … und für den Default-Branch
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
Dein Win Du kannst jetzt sagen: „Dieser Job nur auf main, jener nur im MR, und Drafts lösen gar keine Pipeline aus."

Besonderheiten & Stolperfallen

Doppelte Pipelines Ohne workflow bekommst du leicht zwei Pipelines pro Push in einem MR: eine Branch-Pipeline und eine Merge-Request-Pipeline. Das ist der Klassiker im Workshop – mit workflow: rules entscheidest du dich für eine.
rules und only/except nicht mischen In einem Job ist nur eines erlaubt. Neue Pipelines konsequent mit rules bauen.
Reihenfolge entscheidet Die erste passende Regel gewinnt. Eine breite Regel zuoberst „verschluckt" speziellere darunter – darum spezielle Bedingungen zuerst, allgemeine später.
Default-Branch-Variable statt Name Schreib $CI_DEFAULT_BRANCH statt fest "main". Heisst der Branch mal anders, funktioniert die Regel trotzdem.

Übung für Teilnehmende

Übung 1 · Selbst schreiben

Aufgabe: Ein Job publish soll nur laufen, wenn die Pipeline für einen Tag startet (Release).

Lösung anzeigen 
publish:
  stage: deploy
  script: [./publish.sh]
  rules:
    - if: $CI_COMMIT_TAG

$CI_COMMIT_TAG ist nur bei Tag-Pipelines gesetzt – die Bedingung ist dann „wahr".

Übung 2 · Reihenfolge

Frage: Regel 1 = if: $CI_COMMIT_BRANCH (also jeder Branch), Regel 2 = if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH, when: manual. Wird der Job auf main manuell?

Lösung anzeigen

Nein. Regel 1 trifft auf jeden Branch zu – auch main – und gewinnt, weil sie zuerst steht. Der Job läuft automatisch. Reihenfolge umdrehen, damit die spezielle Regel greift.

Übung 3 · Diagnose

Szenario: Bei jedem Push in einen MR-Branch laufen zwei identische Pipelines. Was hilft?

Lösung anzeigen

Ein workflow: rules-Block, der entweder MR- oder Branch-Pipelines zulässt – nicht beide. Das verhindert die Doppelung.

Kurz prüfen (aus dem Kopf)

Welche Regel einer rules-Liste zählt?

Was steuert workflow: rules?

Primärquelle zum Lesen GitLab Docs – Specify when jobs run with rules.
Frag deinen Teacher. Unsicher bei MR- vs. Branch-Pipelines? Frag nach – das ist erfahrungsgemäss der kniffligste Punkt.
← Lektion 5 Lektion 7 · services (Postgres) →