Generador de Pipelines GitLab CI/CD (.gitlab-ci.yml)
Centro de automatización GitLab CI/CD

Generador de Pipelines GitLab CI/CD (.gitlab-ci.yml)

Referencia técnica para generar canalizaciones de producción de GitLab CI/CD (.gitlab-ci.yml) para entornos Node.js, Python, Go, Rust y Kaniko.

Listo para GitLab CI
Preajustes:
Configuración del entorno Node.js
# ============================================================================
# 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..."
Eficiencia de Pipeline
95%+ Fastzip Enabled
Puntuación de Seguridad
100 / 100SAST Active
Aceleración Estimada
3.5x FasterLockfile Cache

Privacidad 100% del Lado del Cliente

Sintetiza configuraciones de GitLab CI directamente en la memoria del navegador sin transmitir credenciales ni código.

Arquitectura Nativa de GitLab CI

Compatibilidad total con flujos multietapa, compilaciones rootless con Kaniko, caché por lockfile y plantillas de seguridad.

DevSecOps y Rendimiento Reforzado

Integración automática de SAST y detección de secretos, aceleración por compresión Fastzip y cancelación de jobs redundantes.

Referencia técnica y guía de arquitectura

Referencia del Generador de GitLab CI — Guía de referencia

Referencia técnica para generar canalizaciones de producción de GitLab CI/CD (.gitlab-ci.yml) para entornos Node.js, Python, Go, Rust y Kaniko.

Parámetros clave y controles

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

Define el ecosistema de tiempo de ejecución, configurando imágenes de contenedor base, herramientas CLI y scripts estándar de compilación.

Por defecto: 'node'
nodePkgManager'pnpm' | 'npm' | 'yarn' | 'bun'

Selecciona el gestor de paquetes de Node.js, configurando la resolución del lockfile, rutas de caché global y opciones de instalación estricta.

Por defecto: 'pnpm'
cacheKeyType'branch' | 'job' | 'lockfile'

Define la estrategia de generación de claves de caché según la rama de Git, el nombre del trabajo o la suma de comprobación del lockfile.

Por defecto: 'lockfile'
cachePolicy'pull-push' | 'pull' | 'push'

Controla la transferencia de caché del ejecutor; 'pull' solo descarga sin subir cambios, mientras que 'pull-push' actualiza el almacenamiento.

Por defecto: 'pull-push'
dockerEngine'kaniko' | 'dind'

Selecciona el motor de compilación de contenedores: Google Kaniko sin privilegios root o Docker-in-Docker (dind) con modo privilegiado.

Por defecto: 'kaniko'
interruptibleboolean

Habilita la cancelación automática de canalizaciones obsoletas cuando se envían nuevos commits a la misma rama o solicitud de fusión.

Por defecto: true

Consejos profesionales y mejores prácticas

Migrar de Only a Cláusula Rules

Sustituya las directivas obsoletas 'only/except' por bloques modernos 'rules:' con comprobaciones condicionales '$CI_COMMIT_BRANCH'. Permite controlar eventos de solicitud de fusión, puertas de aprobación manual ('when: manual') y cambios en rutas de archivos ('changes:').

Activar Policy Pull en Pruebas

Configure claves de caché basadas en 'key: files: [pnpm-lock.yaml]'. En etapas de pruebas y linting que no añaden dependencias, establezca 'policy: pull' para evitar compresiones innecesarias y latencia de subida al finalizar el trabajo del ejecutor.

Acelerar con DAG y Clave Needs

Supere las barreras rígidas entre etapas añadiendo 'needs: [job_name]' a trabajos independientes. Los trabajos dependientes inician tan pronto como se completa su requisito previo, sin esperar a que finalicen otros trabajos en la etapa anterior.

Compilación Segura con Kaniko

Utilice Google Kaniko ('gcr.io/kaniko-project/executor:debug') en sustitución de Docker-in-Docker. Kaniko compila y publica imágenes de contenedor en espacio de usuario sin privilegios, eliminando la necesidad de habilitar el modo privilegiado en los ejecutores.

Errores comunes y solución de problemas

Trabajo bloqueado en estado pendiente: "This job is stuck because you don't have any active runners online with any of these tags"

Vaya a Configuración > CI/CD > Ejecutores e inspeccione las etiquetas. Asigne la etiqueta de runnerTags a su GitLab Runner o active la opción "Ejecutar trabajos sin etiquetas (Run untagged jobs)" en la configuración del ejecutor si no utiliza etiquetas obligatorias.

Fallo de validación YAML: "jobs:job_name config should implement a script: or a trigger: keyword"

Cada trabajo ejecutable debe definir una matriz 'script:' o una directiva 'trigger:'. Para plantillas reutilizables compartidas, anteceda el nombre del trabajo con un punto (ej. '.base_job:') para declararlo como trabajo oculto e heredarlo mediante 'extends:'.

Error de conexión con Docker: "Cannot connect to the Docker daemon at unix:///var/run/docker.sock"

Al usar Docker-in-Docker ('dind'), confirme que el archivo config.toml del ejecutor tenga 'privileged = true'. Configure las variables de entorno 'DOCKER_HOST: tcp://docker:2375' y 'DOCKER_TLS_CERTDIR: ""' para entornos sin certificados TLS.

Preguntas frecuentes (FAQ)

¿Qué diferencia fundamental existe entre 'cache' y 'artifacts' en GitLab CI?▼

La caché almacena dependencias temporales (como node_modules o .cache) entre ejecuciones para acelerar la compilación, y su ausencia no detiene el trabajo. Los artefactos son entregables definitivos (binarios, informes junit) guardados en GitLab que se transfieren obligatoriamente entre etapas sucesivas.

¿Cómo optimiza la directiva 'needs' el flujo de ejecución frente a las etapas tradicionales?▼

Por defecto, GitLab CI espera a que terminen todos los trabajos de una etapa antes de pasar a la siguiente. Al usar 'needs: [job_name]', se genera un Grafo Acíclico Dirigido (DAG): el trabajo dependiente comienza tan pronto como finaliza su prerrequisito directo, reduciendo drásticamente los tiempos muertos.

¿Cómo se previene la duplicación de canalizaciones en ramas con Merge Requests abiertos?▼

Defina un bloque global 'workflow:rules:' que autorice ejecuciones cuando '$CI_PIPELINE_SOURCE == "merge_request_event"' o en envíos directos a ramas principales sin MR activo. Esta regla suprime la concurrencia redundante entre canalizaciones de rama y de solicitud de fusión.

¿Por qué es preferible Kaniko frente a Docker-in-Docker en clústeres de Kubernetes?▼

Docker-in-Docker exige ejecutar contenedores con privilegios root elevados ('privileged = true'), lo que compromete la seguridad del clúster. Google Kaniko compila y publica imágenes de contenedor completamente en espacio de usuario no privilegiado sin requerir un demonio Docker ni montar sockets.

Herramientas y utilidades relacionadas

Todas las herramientas →