GitLab CI/CD (.gitlab-ci.yml) Pipeline Generator
GitLab CI/CD Automatisierungs-Hub

GitLab CI/CD (.gitlab-ci.yml) Pipeline Generator

Autoritative technische Referenz zur Erstellung produktionsreifer GitLab CI/CD-Pipelines (.gitlab-ci.yml) für Node.js, Python, Go, Rust und Kaniko-Container.

GitLab CI bereit
Vorlagen:
Node.js-Umgebungseinstellungen
# ============================================================================
# GitLab CI/CD Pipeline Configuration (.gitlab-ci.yml)
# Synthesized via ToolsAA Flagship Generator (100% Client-Side Engine)
# ============================================================================

include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml

stages:
  - lint
  - test
  - security
  - build
  - deploy

default:
  image: node:20-alpine
  interruptible: true
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure
  tags:
    - docker
    - saas-linux-medium-amd64

variables:
  FF_USE_FASTZIP: "true"
  ARTIFACT_COMPRESSION_LEVEL: "fast"
  CACHE_COMPRESSION_LEVEL: "fast"
  SAST_EXCLUDED_PATHS: "test, tests, spec, docs"
  NEXT_TELEMETRY_DISABLED: "1"
  CI: "true"

cache:
  key:
    files:
      - pnpm-lock.yaml
  policy: pull-push
  paths:
    - .pnpm-store
    - node_modules/.cache

lint-and-format:
  stage: lint
  timeout: 25m
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
  before_script:
    - npm install -g pnpm
    - pnpm config set store-dir .pnpm-store
    - pnpm install --frozen-lockfile
  script:
    - pnpm run lint
    - pnpm run typecheck

unit-tests:
  stage: test
  timeout: 25m
  parallel:
    matrix:
      - NODE_VERSION: ["18", "20", "22"]
  image: node:${NODE_VERSION}-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
  before_script:
    - npm install -g pnpm
    - pnpm config set store-dir .pnpm-store
    - pnpm install --frozen-lockfile
  script:
    - pnpm test -- --coverage
  coverage: '/Lines\s*:\s*(\d+\.\d+\%)/'
  artifacts:
    reports:
      junit: junit.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
    expire_in: 3 days
    when: always

compile-and-package:
  stage: build
  timeout: 25m
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
  before_script:
    - npm install -g pnpm
    - pnpm install --frozen-lockfile
  script:
    - pnpm run build
  artifacts:
    paths:
      - dist/
      - .next/
      - coverage/
    expire_in: 1 week
    when: on_success

deploy-service:
  stage: deploy
  environment:
    name: production
    url: https://toolsaa.com
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual
  script:
    - echo "Deploying production bundle..."
Pipeline-Effizienz
95%+ Fastzip Enabled
Sicherheitsbewertung
100 / 100SAST Active
Geschwindigkeitsgewinn
3.5x FasterLockfile Cache

100% Client-Side Datenschutz

Erstellt GitLab CI/CD-Pipelines vollständig im lokalen Browserspeicher ohne Übertragung privater Repository-Daten.

GitLab CI Native Architektur

Vollständige Konformität mit Multi-Stage-Ausführung, Kaniko-Builds, Lockfile-Caching und GitLab-Sicherheitsvorlagen.

DevSecOps & Performance-optimiert

Automatische SAST-Integration, Fastzip-Komprimierungsbeschleunigung und Abbruch redundanter Pipelines.

Technische Referenz & Architektur-Leitfaden

GitLab CI Pipeline-Generator Referenz — Referenz-Leitfaden

Autoritative technische Referenz zur Erstellung produktionsreifer GitLab CI/CD-Pipelines (.gitlab-ci.yml) für Node.js, Python, Go, Rust und Kaniko-Container.

Wichtige Parameter & Steuerelemente

ecosystem'node' | 'python' | 'go' | 'rust' | 'docker' | 'pages' | 'generic'

Bestimmt das Ziel-Ökosystem und konfiguriert Basis-Container-Images, CLI-Tools sowie Standardskripte für Node.js, Python, Go, Rust oder Docker.

Standard: 'node'
nodePkgManager'pnpm' | 'npm' | 'yarn' | 'bun'

Wählt den Node.js-Paketmanager aus und steuert die Lockfile-Erkennung, globale Cache-Pfade sowie Flags für unveränderliche Installationen.

Standard: 'pnpm'
cacheKeyType'branch' | 'job' | 'lockfile'

Legt die Strategie für Cache-Schlüssel fest, basierend auf Git-Branch, Job-Namen oder Prüfsummen von Lockfiles zur automatischen Invalidierung.

Standard: 'lockfile'
cachePolicy'pull-push' | 'pull' | 'push'

Steuert das Cache-Verhalten des Runners; 'pull' lädt Archive nur herunter, während 'pull-push' den Cache nach erfolgreichem Job aktualisiert.

Standard: 'pull-push'
dockerEngine'kaniko' | 'dind'

Bestimmt die Container-Build-Engine: unprivilegiertes Google Kaniko oder daemon-basiertes Docker-in-Docker (dind) mit privilegiertem Runner-Modus.

Standard: 'kaniko'
interruptibleboolean

Aktiviert den automatischen Abbruch veralteter Pipelines bei neuen Commits im selben Branch oder Merge Request zur Schonung von Runner-Ressourcen.

Standard: true

Profi-Tipps & Best Practices

Rules statt Only-Syntax nutzen

Ersetzen Sie veraltete 'only/except'-Direktiven durch moderne 'rules:'-Arrays mit Bedingungen wie '$CI_COMMIT_BRANCH'. Dies ermöglicht präzise Kontrolle über Merge-Request-Ereignisse, manuelle Freigaben ('when: manual') und Pfadänderungserkennungen ('changes:').

Pull-Cache in Testjobs aktivieren

Definieren Sie Cache-Schlüssel mit 'key: files: [pnpm-lock.yaml]' zur hashbasierten Invalidierung. In reinen Test- und Lint-Jobs ohne Neuinstallationen verhindert 'policy: pull' zeitaufwendige Upload- und Komprimierungsprozesse am Jobende.

DAG-Ausführung mit Needs steuern

Umgehen Sie lineare Stage-Blockaden, indem Sie unabhängigen Jobs 'needs: [job_name]' zuweisen. Folge-Jobs starten sofort nach Abschluss ihrer direkten Abhängigkeiten, ohne auf unbeteiligte Jobs derselben vorherigen Stage warten zu müssen.

Rootless Kaniko-Builds erzwingen

Nutzen Sie Google Kaniko ('gcr.io/kaniko-project/executor:debug') anstelle von Docker-in-Docker. Kaniko baut und überträgt Container-Images vollständig im unprivilegierten Userspace und eliminiert das Sicherheitsrisiko privilegierter Runner-Konfigurationen.

Häufige Fallstricke & Fehlerbehebung

Job blockiert im Status "pending": "This job is stuck because you don't have any active runners online with any of these tags"

Prüfen Sie unter Einstellungen > CI/CD > Runners die Tags Ihrer Runner. Weisen Sie dem Runner das in runnerTags definierte Tag zu oder aktivieren Sie in den Runner-Einstellungen die Option "Run untagged jobs: true", falls Jobs ohne Tags ausgeführt werden sollen.

YAML-Validierungsfehler: "jobs:job_name config should implement a script: or a trigger: keyword"

Jeder ausführbare Pipeline-Job erfordert entweder ein 'script:'-Array oder ein 'trigger:'-Schlüsselwort. Wenn Sie wiederverwendbare Vorlagen erstellen, stellen Sie dem Jobnamen einen Punkt voran (z. B. '.base_job:'), um einen versteckten Job zu deklarieren, der via 'extends:' geerbt wird.

Docker-Daemon-Verbindungsfehler: "Cannot connect to the Docker daemon at unix:///var/run/docker.sock"

Bei Docker-in-Docker ('dind') muss in der config.toml des Runners 'privileged = true' gesetzt sein. Setzen Sie zudem die Umgebungsvariablen 'DOCKER_HOST: tcp://docker:2375' und 'DOCKER_TLS_CERTDIR: ""', falls die TLS-Zertifikatsvalidierung deaktiviert ist.

Häufig gestellte Fragen (FAQ)

Was unterscheidet den GitLab CI-Cache von Artifacts bei mehrstufigen Pipelines?▼

Cache speichert temporäre Abhängigkeiten (z. B. node_modules oder .pnpm-store) zwischen Pipeline-Läufen auf dem Runner oder S3-Speicher; ein Cache-Miss verhindert nicht den Job-Erfolg. Artifacts sind unveränderliche Build-Ergebnisse und Testberichte, die garantiert an nachfolgende Stages übergeben und in GitLab archiviert werden.

Welchen Performance-Vorteil bietet das Schlüsselwort 'needs' gegenüber linearen Stages?▼

Standard-Pipelines warten, bis ausnahmslos alle Jobs einer Stage fertig sind, bevor die nächste beginnt. Durch 'needs: [job_name]' entsteht ein gerichteter azyklischer Graph (DAG): Nachgelagerte Jobs starten sofort nach Abschluss ihrer deklarierten Abhängigkeiten, ohne von langsameren Jobs früherer Stages blockiert zu werden.

Wie verhindert man doppelte Pipelines bei Push-Events und offenen Merge Requests?▼

Konfigurieren Sie einen globalen 'workflow:rules:'-Abschnitt: Lassen Sie Pipelines laufen, wenn '$CI_PIPELINE_SOURCE == "merge_request_event"' zutrifft oder bei Pushes auf Standard-Branches ohne offenen MR. Dadurch wird die gleichzeitige Ausführung doppelter Pipelines zuverlässig unterbunden.

Warum wird Kaniko gegenüber Docker-in-Docker in Kubernetes-Umgebungen bevorzugt?▼

Docker-in-Docker erfordert zwingend den privilegierten Root-Modus ('privileged = true'), was erhebliche Sicherheitsrisiken für den Cluster darstellt. Google Kaniko führt Image-Builds vollständig im unprivilegierten Userspace aus, benötigt keinen Docker-Daemon und greift nicht auf den Docker-Socket des Host-Knotens zu.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →