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.

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.

→ 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 di Github e aggiungerle al tuo flusso di lavoro direttamente quando soddisfano le tue esigenze.

Quanto descritto finora è riassumibile nella seguente immagine:

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, qualsiasi sequenza di comandi che avvieresti manualmente su una macchina virtuale remota può essere avviata all’interno di un workload: 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, 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