Die kleinen Keywords, die im echten Betrieb den Unterschied machen.
Warum eine Component-Version pinnen?
Feste Version statt beweglichem latest/Branch – bewusst aktualisieren.
Geheimnisse gehören nie ins YAML, sondern in CI/CD-Variablen (Projekt → Settings → CI/CD):
[MASKED] ersetzt.retryintegration-test:
script: [pytest tests/integration]
retry:
max: 2 # bis zu 2 Wiederholungen
when:
- runner_system_failure # nur bei Infra-Problemen wiederholen
- stuck_or_timeout_failure
retry: max: 2 allein wiederholt bei jedem Fehler – das maskiert echte Bugs. Besser mit
when: nur Infrastruktur-Fehler wiederholen, nicht fachliche.
interruptibledefault:
interruptible: true
workflow:
auto_cancel:
on_new_commit: interruptible
Pusht jemand schnell hintereinander, bricht GitLab die jetzt überholten, noch laufenden Pipelines ab. Das spart Runner-Zeit und gibt schneller Feedback auf den neuesten Stand. Deploy-Jobs lässt man besser nicht interruptible.
timeoute2e-test:
timeout: 20 minutes # statt stundenlang am Projekt-Timeout zu hängen
script: [./run-e2e.sh]
expire_in setzen, sonst füllt sich der Speicher..gitlab-ci.yml, bevor du committest.CI_DEBUG_TRACE: "true": ausführliches Job-Log – Vorsicht, kann Secrets zeigen, nur kurz nutzen.script bis zu Secrets, Retries und Kostenkontrolle: Du hast den vollen Werkzeugkasten,
um produktionsreife GitLab-Pipelines zu bauen und zu vermitteln.
Frage: Ein Prod-Deploy-Token darf nur auf main verfügbar sein. Welche zwei
Eigenschaften gibst du der CI/CD-Variable?
Masked (nicht im Log sichtbar) und Protected (nur auf protected Branches/Tags,
z. B. main). Feature-Branches sehen das Token dann gar nicht.
Frage: Warum ist retry: max: 2 ohne when: oft eine schlechte
Idee?
Es wiederholt bei jedem Fehler – auch bei echten Bugs. Ein kaputter Test wird so gelegentlich „zufällig" grün und versteckt das Problem. Lieber nur Infra-Fehler wiederholen.
Aufgabe: Nenne drei konkrete Stellschrauben, um Pipeline-Kosten zu senken.
Z. B.: (1) expire_in für Artifacts, (2) Matrix klein halten, (3) teure Jobs
per rules nur auf main/Tags, (4) interruptible + auto-cancel,
(5) Cache-Keys verbessern. Drei davon genügen.
Was leistet eine maskierte CI/CD-Variable?
Masking ersetzt den Wert im Log durch [MASKED] – kein Tresor, nur Leak-Schutz.
Wofür ist interruptible gedacht?
Mit auto-cancel bricht GitLab veraltete Läufe ab und spart Runner-Zeit.