GitLab CI — Cheat Sheet

Tag: gitlab, gitlab-ci, devops, ci-cd, pipelines, yaml, docker

Livello: intermedio

TL;DR: Sintassi, architettura runner ed esecuzione pipeline in .gitlab-ci.yml. Riferimento rapido per configurazione stage, cache, artefatti e regole di esecuzione.

Concetti chiave

Pipeline definita nel repository tramite il file .gitlab-ci.yml.

Struttura basata su stage sequenziali contenenti job eseguiti in parallelo.

GitLab Runner isola l'esecuzione su host dedicati, container o cluster Kubernetes.

artifacts passa file e build tra stage diversi della stessa pipeline.

cache condivide dipendenze tra pipeline successive per velocizzare i job.

rules sostituisce only/except per controllare quando eseguire un job.

needs crea dipendenze dirette tra job scavalcando l'ordine rigido degli stage (DAG).

Variabili CI/CD gestiscono segreti, configurazioni di ambiente e token protetti.

Environments e deployment tracciano i rilasci su ambienti di staging e produzione.

Domande tipiche e risposte pronte

Q: Qual e la differenza tra cache e artifacts in GitLab CI?R: Uso gli artifacts per trasferire output di build tra stage della stessa pipeline. Uso la cache per memorizzare dipendenze esterne come node_modules tra esecuzioni diverse.

Q: Come velocizzi una pipeline complessa con molti stage?R: Imposto needs per creare grafi aciclici diretti tra job indipendenti, configuro cache mirata per lockfile e uso immagini Docker snelle pre-costruite.

Q: Come gestisci il deploy sicuro su produzione evitando trigger indesiderati?R: Configuro regole con rules:when: manual sui branch protetti e isolo le credenziali sensibili come variabili protette e mascherate per ambiente.

Insidie e errori comuni

Confondere cache con artifacts causando build fallite per file mancanti tra runner.

Dimenticare pull-push o policy inadeguate sulla cache che rallentano l'upload inutile.

Usare immagini Docker troppo pesanti senza layer pre-installati per i task comuni.

Sovrascrivere before_script globale nei singoli job perdendo setup critici.

Esporre variabili non mascherate nei log dei job tramite comandi verbosi.

Snippet e comandiYAML

```stages:

• test
• build
• deploy

default:

image: node:20-alpine

cache:

key:

files:

• package-lock.json

paths:

• .npm/

unit-tests:

stage: test

script:

• npm ci --cache .npm --prefer-offline
• npm test

build-app:

stage: build

script:

• npm run build

artifacts:

name: dist-$CI_COMMIT_SHORT_SHA

paths:

• dist/

expire_in: 1 week

deploy-prod:

stage: deploy

needs:

• build-app

script:

• ./scripts/deploy.sh

environment:

name: production

url: https://example.com

rules:

• if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

when: manual

```

Da ripassare

[ ] Sintassi avanzata della direttiva rules con clausole changes ed exists.

[ ] Architettura e configurazione degli executor per GitLab Runner.

[ ] Inclusione di template riutilizzabili tramite include:local e include:remote.

[x] Differenza pratica e ciclo di vita tra cache e artifacts.

[x] Configurazione base di stage e job sequenziali.

Riferimenti

GitLab CI/CD Documentation (docs.gitlab.com/ee/ci/)

GitLab CI/CD Pipeline Configuration Reference (.gitlab-ci.yml reference)