GitHub Actions — Cheat Sheet

Tag: github, actions, ci, cd, yaml, workflow, automation

Livello: intermedio

TL;DR: Riferimento rapido per GitHub Actions: architettura dei workflow, gestione dei job, trigger, secret e sintassi essenziale in YAML.

Concetti chiave

I *Workflow* sono processi automatizzati configurabili definiti in file YAML sotto .github/workflows/.

Un workflow è composto da uno o più *Job*, che di default vengono eseguiti in parallelo.

I *Job* definiscono l'ambiente di esecuzione (es. ubuntu-latest) e sono composti da *Step*.

Gli *Step* vengono eseguiti in ordine sequenziale sullo stesso runner e condividono il filesystem.

Uno step può eseguire uno script shell o usare un'*Action* (componente logico riutilizzabile).

Gli *Eventi* (trigger) determinano quando il workflow si avvia (es. push, pull_request, schedule).

I *Runner* sono i server che eseguono i workflow (GitHub-hosted o self-hosted).

I *Secret* permettono di iniettare dati sensibili e password criptate nell'ambiente di esecuzione.

Le *Matrix build* permettono l'esecuzione parallela dello stesso job con combinazioni di variabili diverse.

Domande tipiche e risposte pronte

Q: Qual è la differenza tra workflow, job e step in GitHub Actions?R: Il workflow è l'intero processo. Contiene i job, che girano su runner indipendenti in parallelo. I job contengono gli step, che sono eseguiti in sequenza e condividono i dati sullo stesso runner.

Q: Come fai a eseguire un job solo dopo il completamento di un altro?R: Uso la direttiva needs nel job dipendente, passando l'identificativo del job che deve terminare con successo.

Q: Come eviti che i workflow girino su modifiche a file markdown o documentazione?R: Imposto i filtri paths o paths-ignore nella definizione del trigger del workflow per escludere o includere file specifici.

Insidie e errori comuni

Dimenticare l'action actions/checkout@v4 all'inizio del job, ritrovandosi senza il codice sorgente nel runner.

Usare versioni mobili delle action di terze parti (es. @master) esponendosi a rotture improvvise; meglio fissare major o tag specifici.

Esporre involontariamente secret stampandoli nei log con echo senza usare le funzioni di mascheramento.

Usare artifact tra step anziché tra job: gli step condividono lo spazio su disco e non necessitano di upload/download artifact.

Snippet e comandiYAML

```name: CI Workflow

on:

push:

branches:

• main

pull_request:

branches:

• main

jobs:

build:

runs-on: ubuntu-latest

steps:

• name: Checkout repository

uses: actions/checkout@v4

• name: Setup Node.js

uses: actions/setup-node@v4

with:

node-version: '20'

• name: Install dependencies

run: npm ci

• name: Run tests

run: npm test

env:

API_KEY: ${{ secrets.MY_API_KEY }}

deploy:

needs: build

runs-on: ubuntu-latest

if: github.ref == 'refs/heads/main'

steps:

• name: Deploy step

run: echo "Deploying application..."

```