Linting aus vier Schichten — statt einem Mega-Linter

Es ist Mai 2022, und MegaLinter hat 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 für Sprachen sind, die du gar nicht im Stack 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 von rund 20–30 MB), schnell (Sekunden) und hat ein klares Aufgabenfeld. Pin auf konkrete Versionen — hadolint:2.10-alpine, nicht :latest — sonst kippt dir ein 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

Zwei Stages, vier Schicht-Jobs. Hier eine Forgejo-/GitHub-Actions-Skizze, die du in fünf Minuten an dein Repo anpassen kannst:

# .github/workflows/lint.yml (Forgejo-Workflows-Syntax identisch)
name: lint
on: [push, pull_request]

jobs:
  konvention:
    runs-on: ubuntu-22.04
    container:
      image: commitlint/commitlint:18-alpine
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: commitlint --from=origin/main

  sprache:
    needs: [konvention]
    runs-on: ubuntu-22.04
    container:
      image: hadolint/hadolint:v2.10.0-alpine
    steps:
      - uses: actions/checkout@v4
      - run: hadolint Dockerfile

  format:
    needs: [konvention]
    runs-on: ubuntu-22.04
    container:
      image: davidanson/markdownlint-cli2:v0.5.1
    steps:
      - uses: actions/checkout@v4
      - run: markdownlint-cli2 '**/*.md'

  domain:
    needs: [konvention]
    runs-on: ubuntu-22.04
    container:
      image: stoplight/spectral:6.4
    steps:
      - uses: actions/checkout@v4
      - run: spectral lint openapi/*.yaml

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 lint läuft, ist exakt dasselbe wie die CI-Jobs. Sonst ist die Pipeline ein Feedback-Loop mit Drei-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.