GitHub Actions 101
Published: 2023-10-03 14:24:40

---
title: GitHub Actions 101
published: true
date: 2023-03-07 00:00:00 UTC
tags: 
canonical_url: 
---

Probabilmente hai familiarità con GitHub: sai già che si tratta di una piattaforma straordinaria per creare software, collaborare con i tuoi colleghi di team e contribuire a progetti open source.

GitHub offre molte funzionalità che ti semplificano la vita come sviluppatore o sviluppatrice.

In questo articolo, parleremo di come lavorare con una feature su GitHub **killer** estremamente potente e sempre sottovalutata: GitHub Actions.

# Cosa vedrai

- [GitHub Actions](#github-actions)
- [Componenti](#componenti)
- [Scopo](#scopo)
- [Come funziona](#come-funziona)
- [Risorse utili](#risorse-utili)

# GitHub Actions

GitHub Actions è una piattaforma che automatizza la creazione, il test e la distribuzione del software. Ma non si ferma qui: ti permette anche di eseguire qualsiasi tipo di operazione sul tuo repository quando si verifica un evento specifico.

# Componenti

Per avere un quadro completo di cosa sia GitHub Actions, aiuta a scomporlo nei suoi numerosi componenti:

→ **Eventi**

Un **evento** è tutto ciò che può accadere su un repository GitHub. Questo va dal push di un codice, alla creazione di un branch, all’apertura di una richiesta di pull e persino al commento di un problema. L’elenco dei trigger è molto più lungo: puoi verificarlo [qui](https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#webhook-events).

→ **Workload**

Un **flusso**  **di**  **lavoro** è un processo automatizzato composto da una serie di lavori che viene eseguito quando viene attivato da un evento.

I **workload** sono definiti nei file YAML e sono archiviati in una directory .github/workflows nella radice del repository. Un repository può anche avere più flussi di lavoro.

→ **Job**

Un _job_ è una serie di attività che vengono eseguite in un flusso di lavoro dopo essere state attivate da un evento. Ogni passaggio è uno script o un’azione GitHub. Un flusso di lavoro può avere più _jobs_ eseguiti in parallelo.

→ **Runner**

I **runner** sono processi su un server che eseguono il flusso di lavoro quando viene attivato. Ogni runner è responsabile dell’esecuzione di un determinato lavoro. I **runner** sono ospitati nel cloud ma possono anche essere ospitati autonomamente in ambienti cloud personalizzati.

→ **Actions**

Le **azioni** sono attività individuali: sono chiamate all’interno di un _workload_ e vengono utilizzate per eseguire attività complesse che puoi richiamare più volte.

Alcuni esempi di azioni sono: pubblicazione di un pacchetto Python su PyPi, invio di un’e-mail di notifica, impostazione di Python su una versione specifica prima di eseguire uno script, ecc.

Puoi creare le tue azioni oppure puoi riutilizzare alcune azioni open source dal [marketplace](https://github.com/marketplace?type=actions) di Github e aggiungerle al tuo flusso di lavoro direttamente quando soddisfano le tue esigenze.

Quanto descritto finora è riassumibile nella seguente immagine:

![](https://theredcode.it/img/github-actions-schema.png)

# Scopo

L’obiettivo dell’aggiunta di Github Actions è fondamentalmente quello di **automatizzare** le attività che vorresti fossero eseguite ripetutamente ad ogni specifico evento.

Facciamo un esempio qui: immagina che ogni volta che committi un nuovo pezzo di codice sul tuo repository, ti piacerebbe eseguire una serie di _unit_ _test_ su di esso attraverso una macchina Ubuntu che ha una configurazione specifica.

Come fare?

Un’opzione è quella di eseguire il push del codice su GitHub, connettersi al server dove vuoi eseguire i test, aggiornare il codice, eseguire i test e attendere l’output finale. Inutile dire che è un processo noioso e lungo.

Grazie alla creazione di una GitHub Action, è sufficiente creare un workload che venga eseguito ad ogni push e che esegua la stessa serie di azioni descritta poco fa: avviare un server, fare il checkout del codice, eseguire una serie di unit test e mostrare i risultati in una console.

# Come funziona

Ogni flusso di lavoro è definito in un file YAML all’interno della cartella _workflows_ nel repository.

Un esempio estremamente semplice è il seguente: ad ogni push sul repository (sezione _on_) nel branch chiamato _main_, esegui un job (sezione _jobs_) chiamato _print\_hello_ e utilizza un runner basato su Ubuntu (sezione _runs-on_) per stampare “Hello world” nella console (sezione _steps_):

```
on:
 push:
 branches:
 - main

jobs:
 print_hello:
 runs-on: ubuntu-latest
 steps:
 - run: echo "Hello World!"

```

Questo esempio è volutamente molto semplice ma dovrebbe dare un’idea delle infinite possibilità offerte da Github Actions: infatti, <ins>qualsiasi sequenza di comandi che avvieresti manualmente su una macchina virtuale remota può
essere avviata all’interno di un workload</ins>: questo può essere una serie di unit test, una serie di fasi di compilazione Docker, una distribuzione di un’API, ecc.

> In sintesi, qualsiasi cosa tu possa immaginare di fare, può essere attivata e automatizzata per l’esecuzione tramite una GitHub Action.

Puoi saperne di più sulla sintassi tramite la documentazione presente [qui](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions), ma ecco alcune istruzioni fondamentali:

- **on** : l’evento che attiva il workload
- **runs-on** : la macchina che ogni lavoro dovrebbe eseguire (ad esempio _ubuntu-latest_)
- **jobs** : l’elenco delle attività che compongono il flusso di lavoro
- **steps** : la serie di attività che vengono eseguite all’interno di ogni job
- **run** : il comando che viene eseguito

# Risorse utili

- [Documentazione ufficiale](https://docs.github.com/en/actions)