Es ist Mai 2022, und MegaLinter ist gewonnen. Wer heute ein neues Repo aufmacht und Linting braucht, sieht MegaLinter auf Stack Overflow, in Dev-Blogs, in jedem zweiten Pull-Request- Template. Ein Image, hundert Linter, ein YAML, fertig. Für 80 % der Repos ist das genau richtig.
Dieser Artikel ist für die anderen 20 %. Die, in denen das MegaLinter-Image deine CI um vier Minuten verlängert. In denen 95 der eingebauten Linter Tools sind, die du nicht hast. In denen ein generischer Fail-Output dir sagt »MegaLinter findet Probleme« und du erst die MegaLinter-Doku öffnen musst, um zu wissen, welcher der hundert Linter gerade etwas zu sagen versucht.
Die Alternative: vier saubere Schichten, jede mit klarem Zuständigkeitsbereich, alle einzeln pinbar.
Schicht 1 — Sprach-Linter
Prüfen syntaktische Korrektheit und sprach-spezifische Best
Practices. Die Pflicht-Schicht — ohne sie geht nichts in main.
Typische Tools: hadolint für Dockerfiles,
tflint für Terraform/OpenTofu,
ShellCheck für Bash, yamllint für
generische YAMLs, actionlint für GitHub-Actions-
Workflows.
Jedes dieser Tools ist klein (Alpine-Images um 20-30 MB),
schnell (Sekunden) und hat ein klares Aufgabenfeld. Pin auf
konkrete Versionen — hadolint:2.10-alpine, nicht
:latest — sonst kippt dir eine Major-Update die
Pipeline.
Schicht 2 — Format-Linter
Prüfen, ob Dateien einheitlich strukturiert sind. Die
Hygiene-Schicht. Typische Tools: markdownlint für
Markdown, Prettier für JS/TS/CSS/JSON/YAML,
editorconfig-checker für Sprach-übergreifende
Konvention.
Trennlinie zu Schicht 1: Schicht 1 fragt »ist es korrekt?«,
Schicht 2 fragt »liest es sich konsistent?«. Format-Linter
haben oft eine --fix-Option — lokal in
pre-commit erlauben, in CI nur prüfen.
Schicht 3 — Konvention-Linter
Prüfen Git-Metadaten — Commits, Branch-Namen, Release-Notes.
Die Workflow-Schicht. Wichtigstes Tool: commitlint
mit @commitlint/config-conventional.
Diese Schicht läuft sequenziell vor den anderen, weil bei kaputter Commit-Message der Rest egal ist. semantic-release und automatische Versionierung sind ohne Konvention-Linter ein Kartenhaus.
Schicht 4 — Domain-Linter
Prüfen fachliche Strukturen — OpenAPI-Specs, Feature-Files,
Helm-Charts. Die Vertrags-Schicht. Typische Tools:
Spectral für OpenAPI/AsyncAPI,
gherkin-lint für BDD-Features,
helm lint und kubeconform für
Kubernetes-Manifeste.
Diese Schicht läuft nur, wenn relevante Dateien geändert wurden (Path-Filter). Spart CI-Zeit, denn nicht jeder Commit fasst Domain-Files an.
Wie das in deiner Pipeline aussieht
Drei Stages, vier Schicht-Jobs:
- Stage 1 — Konvention. commitlint, sequenziell.
- Stage 2 — Sprache + Format + Domain. Drei Jobs parallel.
Gesamt-Laufzeit nach Cache-Warmup: typisch 90-120 s. MegaLinter-Pendant: 6-8 min. Faktor 4-5 schneller, mit klareren Fehler-Outputs und einzeln pinbaren Tool-Versionen.
Was du jetzt mitnehmen kannst
Drei Faustregeln:
- Pinne alle Tool-Versionen. Keine
:latest-Tags. Ein Tool-Upgrade ist ein PR. - Lokal = CI. Was lokal mit
just lintläuft, ist exakt dasselbe wie die CI-Jobs. Sonst ist die Pipeline ein Feedback-Loop mit 3-Minuten-Verzögerung. - Eine Schicht pro Quartal. Wenn dein Repo noch nicht geschichtet ist, starte mit Schicht 1. Alle vier auf einmal ist Team-Frust.
Wenn du tiefer einsteigen willst
Das Kurzbuch „Linting in Schichten — Vier Schichten statt einem Mega-Linter" entwickelt jede Schicht über ein eigenes Kapitel mit Setup-Snippets pro Tool, CI- und Pre-Commit-Konfigurationen für GitHub Actions, GitLab CI und Forgejo Actions, sowie ein durchgespieltes Beispiel an einem Postgres-Operator-Repo. Drei Diagramme, ein Cheatsheet zum Aushängen. Rund 80 Seiten, 90 Minuten Lesezeit. Erschienen Mai 2022 als Taschenbuch und eBook über epubli.