In che modo GitHub Actions consente di automatizzare le attività di sviluppo?

  • 10 minuti

In questa sezione vengono presentati GitHub Actions e i flussi di lavoro. Vengono illustrati i tipi di azioni che è possibile usare e dove trovarli. Si esaminano anche esempi di questi tipi di azioni e il modo in cui si adattano a un flusso di lavoro.

Con GitHub viene ridotto il tempo dall'idea iniziale alla distribuzione

GitHub è progettato per aiutare i team di sviluppatori e tecnici DevOps a creare e distribuire rapidamente le applicazioni. In GitHub sono disponibili molte funzionalità che consentono queste efficienze, ma in genere rientrano in una delle due categorie seguenti:

  • Comunicazione: tenere presenti tutti i modi in cui GitHub semplifica la comunicazione di un team di sviluppatori sul progetto di sviluppo del software, ad esempio revisioni del codice nelle richieste pull, problemi di GitHub, bacheche dei progetti, wiki, notifiche e così via.
  • Automazione: GitHub Actions consente al team di automatizzare i flussi di lavoro in ogni passaggio del processo di sviluppo software, dall'integrazione alla distribuzione. Consente inoltre di automatizzare l'aggiunta di etichette alle richieste pull e il controllo di eventuali problemi di aggiornamento e delle richieste pull.

Usate in combinazione, queste funzionalità hanno consentito a migliaia di team di sviluppo di ridurre in modo efficace il tempo necessario dall'idea iniziale alla distribuzione.

Usare l'automazione del flusso di lavoro per ridurre i tempi di sviluppo

In questo modulo ci si concentra sull'automazione. Verrà dedicato tempo alla comprensione del modo in cui i team possono usare l'automazione per ridurre il tempo necessario per completare un flusso di lavoro tipico per lo sviluppo e la distribuzione.

Tenere presenti tutte le attività che devono essere eseguite dopo che il codice è stato scritto ma prima che possa essere usato in modo affidabile per lo scopo previsto. A seconda degli obiettivi dell'organizzazione, è probabile che sia necessario eseguire una o più delle attività seguenti:

  • Assicurarsi che il codice superi tutti gli unit test.
  • Eseguire controlli di conformità e qualità del codice per verificare che il codice sorgente soddisfi gli standard dell'organizzazione.
  • Controllare il codice e le relative dipendenze per individuare eventuali problemi di sicurezza noti.
  • Compilare il codice integrando il nuovo codice sorgente possibilmente da più collaboratori.
  • Verificare che il software superi i test di integrazione.
  • Specificare la versione della nuova build.
  • Inviare i nuovi file binari al percorso del file system appropriato.
  • Distribuire i nuovi file binari in uno o più server.
  • Determinare se una di queste attività non supera la verifica e segnalare il problema alla persona o al team appropriato per la risoluzione.

La sfida consiste nell'eseguire queste attività in modo affidabile, coerente e sostenibile. Questo processo è un processo ideale per l'automazione del flusso di lavoro. Se si fa già affidamento su GitHub, è probabile che si voglia configurare l'automazione del flusso di lavoro usando GitHub Actions.

Che cosa sono le azioni di GitHub Actions?

Le azioni di GitHub Actions sono script pacchettizzati per automatizzare attività all'interno di un flusso di lavoro di sviluppo software in GitHub. È possibile configurare GitHub Actions per attivare flussi di lavoro complessi che soddisfano le esigenze dell'organizzazione. Il trigger può essere attivato ogni volta che gli sviluppatori archiviano nuovo codice sorgente in un ramo specifico, in base a intervalli di tempo specifici o manualmente. Il risultato è un flusso di lavoro automatizzato affidabile e sostenibile con una riduzione significativa dei tempi di sviluppo.

Dove trovare GitHub Actions?

GitHub Actions sono script conformi al formato di dati yml. Ogni repository include una scheda Actions (Azioni) che offre un modo semplice e rapido per iniziare a configurare il primo script. Se viene visualizzato un flusso di lavoro che si ritiene possa essere un ottimo punto di partenza, è sufficiente selezionare il pulsante di configurazione per aggiungere lo script e iniziare a modificare il file yml di origine.

Screenshot della *scheda Actions* in GitHub Actions che illustra un semplice flusso di lavoro e un pulsante per configurare tale flusso di lavoro.

Tuttavia, oltre alle azioni di GitHub Actions disponibili nella scheda Actions (Azioni), è possibile:

  • Cercare GitHub Actions nel marketplace GitHub. Nel marketplace GitHub si possono trovare e acquistare strumenti per l'estensione del flusso di lavoro.
  • Cercare progetti open source. Ad esempio, l'organizzazione GitHub Actions offre molti repository open source popolari contenenti azioni di GitHub Actions utilizzabili.
  • Scrivere da zero le proprie GitHub Actions. È possibile renderli open source o anche pubblicarli in GitHub Marketplace.

Uso di GitHub Actions open source

Molte funzionalità di GitHub Actions sono open source e disponibili per chiunque voglia usarle. Come per qualsiasi software open source, tuttavia, è necessario verificarle attentamente prima di usarle nel progetto. Analogamente agli standard della community consigliati per gli altri software open source, come l'inclusione di un file Leggimi, di un codice di condotta, di un file dei contributi e di modelli di problemi, è possibile seguire le raccomandazioni seguenti quando si usa GitHub Actions:

  • Controllare il file action.yml dell'azione per gli input e gli output e per verificare che il codice consenta effettivamente di eseguire le azioni previste.
  • Verificare che l'azione si trovi nel Marketplace GitHub. Questo controllo è utile, anche se non è necessario che un'azione sia valida in GitHub Marketplace.
  • Controllare che l'azione sia verificata nel Marketplace GitHub. La verifica indica che GitHub ha approvato l'uso di questa azione. Prima di usarla, tuttavia, è sempre necessario controllarla.
  • Includere la versione dell'azione in uso specificando un riferimento Git, un SHA o un tag.

Tipi di azioni di GitHub

Esistono tre tipi di azioni GitHub: azioni contenitore, azioni JavaScript e azioni composite.

Con le azioni del contenitore, l'ambiente fa parte del codice dell'azione. Queste azioni possono essere eseguite solo in un ambiente Linux ospitato da GitHub. Le azioni del contenitore supportano molti linguaggi diversi.

Le azioni JavaScript non includono l'ambiente nel codice. È necessario specificare l'ambiente per eseguire queste azioni. L'esecuzione di queste azioni può avvenire in una VM (macchina virtuale) nel cloud o in locale. Le azioni JavaScript supportano ambienti Linux, macOS e Windows.

Le azioni composte consentono di combinare più passaggi del flusso di lavoro all'interno di un'azione. Ad esempio, puoi usare questa funzionalità per raggruppare più comandi di esecuzione in un'azione e quindi avere un flusso di lavoro che esegue i comandi in bundle come singolo passaggio usando tale azione.

Anatomia di un'azione GitHub

Di seguito è riportato un esempio di azione che esegue il comando git checkout di un repository. Questa azione, actions/checkout@v1, è parte di un passaggio in un flusso di lavoro. Questo passaggio compila anche il codice Node.js di cui è stato eseguito il checkout. Flussi di lavoro, processi e passaggi verranno illustrati nella sezione successiva.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Si supponga di voler usare un'azione del contenitore per eseguire il codice incluso in un contenitore. L'azione sarà come segue:

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Si noti la sezione inputs. Qui si ottiene il valore della variabile denominata MY_NAME. Questa variabile viene impostata nel flusso di lavoro che esegue questa azione.

Nella sezione runs si noti che nell'attributo viene specificato uses. Quando si imposta questo valore, è necessario specificare il percorso del file di immagine Docker. In questo caso, Dockerfile. Le specifiche di Docker non sono disponibili qui, ma per altre informazioni, vedere il modulo Introduzione ai contenitori Docker .

L'ultima sezione, branding, personalizza la tua azione nel Marketplace GitHub se decidi di pubblicarla lì.

È possibile trovare un elenco completo dei metadati delle azioni in Sintassi dei metadati per le azioni di GitHub Actions.

Che cos'è un flusso di lavoro di GitHub Actions?

Un flusso di lavoro di GitHub Actions è un processo configurato nel repository per automatizzare le attività del ciclo di vita dello sviluppo software, comprese le azioni di GitHub Actions. Con un flusso di lavoro è possibile compilare, testare, aggiungere a un pacchetto, rilasciare e distribuire qualsiasi progetto in GitHub.

Per creare un flusso di lavoro, è possibile aggiungere azioni a un file con estensione yml nella directory .github/workflows del repository GitHub.

Nell'esercizio in arrivo, il file del flusso di lavoro main.yml è simile all'esempio seguente:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Si noti l'attributo on:, il cui valore è un trigger per specificare quando questo flusso di lavoro viene eseguito. In questo caso attiva un'esecuzione quando è presente un evento push nel repository. È possibile specificare singoli eventi come on: push, una matrice di eventi come on: [push, pull_request] o una mappa di configurazione di eventi che pianifica un flusso di lavoro o limita l'esecuzione di un flusso di lavoro a file, modifiche del ramo o tag specifici. Tale mappa sarà simile alla seguente:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

Viene attivato un evento su tutti i tipi di attività per l'evento, a meno che non si specifichi il tipo o i tipi. Per un elenco completo degli eventi e dei relativi tipi di attività, vedere: Eventi che attivano i flussi di lavoro nella documentazione di GitHub.

È necessario che un flusso di lavoro includa almeno un processo. Un processo è una sezione del flusso di lavoro associata a uno strumento di esecuzione. Uno strumento di esecuzione può essere ospitato in GitHub o self-hosted e il processo può essere eseguito in un computer o in un contenitore. Specificare lo strumento di esecuzione con l'attributo runs-on:. In questo caso si indica al flusso di lavoro di eseguire il processo in ubuntu-latest.

Ogni processo prevede passaggi da completare. In questo esempio il passaggio usa l'azione actions/checkout@v1 per estrarre il repository. È interessante notare il valore uses: ./action-a, ovvero il percorso per l'azione contenitore creata in un file action.yml.

Nell'ultima parte di questo file del flusso di lavoro viene impostato il valore della variabile MY_NAME per il flusso di lavoro. Ricordare che l'azione del contenitore ha accettato un input denominato MY_NAME.

Per ulteriori informazioni sulla sintassi del flusso di lavoro, vedere Sintassi del flusso di lavoro per GitHub Actions

Riferimento alle azioni nei flussi di lavoro

Quando si creano flussi di lavoro in GitHub Actions, è possibile fare riferimento ad azioni da diverse origini. Queste azioni possono essere usate per automatizzare le attività nei flussi di lavoro. Di seguito sono riportate le origini principali in cui i flussi di lavoro possono fare riferimento alle azioni:

  1. Immagine del contenitore Docker pubblicata nell'hub Docker
    I flussi di lavoro possono fare riferimento a azioni pubblicate come immagini del contenitore Docker nell'hub Docker. Queste azioni sono incluse in contenitori e includono tutte le dipendenze necessarie per eseguire l'azione. Per usare tale azione, specificare l'immagine Docker nell'attributo uses del passaggio del flusso di lavoro. Per esempio:

    steps:
  - name: Run a Docker action
    uses: docker://<docker-image-name>:<tag>

  2. Qualsiasi repository pubblico
    Le azioni ospitate nei repository pubblici possono essere referenziate direttamente nei flussi di lavoro. Queste azioni sono accessibili a chiunque e possono essere usate specificando il nome e la versione del repository (riferimento Git, SHA o tag) nell'attributo uses . Per esempio:

    steps:
  - name: Use a public action
    uses: actions/checkout@v3

[IMPORTANTE!]

Per una maggiore sicurezza, usare uno SHA di commit completo quando si fa riferimento alle azioni, non solo un tag come @v3.
In questo modo, il flusso di lavoro usa sempre lo stesso codice esattamente, anche se l'azione viene aggiornata o modificata in un secondo momento.
Esempio: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

  1. Lo stesso repository del file di workflow
    È possibile fare riferimento alle azioni archiviate nello stesso repository del file del flusso di lavoro. Questa funzionalità è utile per azioni personalizzate specifiche del progetto. Per fare riferimento a tali azioni, usare un percorso relativo alla cartella dell'azione. Per esempio: 
    steps:
  - name: Use a local action
    uses: ./path-to-action

Per altre informazioni, vedere Linee guida per la protezione avanzata per GitHub Actions.

  1. Un marketplace aziendale
    Se l'organizzazione usa GitHub Enterprise, è possibile fare riferimento alle azioni del marketplace privato dell'azienda. Queste azioni vengono curate e gestite dall'organizzazione, garantendo la conformità agli standard interni. Per esempio: 
    steps:
  - name: Use an enterprise marketplace action
    uses: enterprise-org/action-name@v1

Annotazioni

  • È anche possibile fare riferimento alle azioni nei repository privati, ma richiedono l'autenticazione e le autorizzazioni appropriate.
  • Quando si fa riferimento alle azioni, specificare sempre una versione (riferimento Git, SHA o tag) per garantire la coerenza ed evitare modifiche impreviste.

Per altre informazioni, vedere Riferimenti alle azioni nei flussi di lavoro.

Strumenti di esecuzione self-hosted e ospitati da GitHub

Abbiamo accennato brevemente ai corridori come associati a un lavoro. Un runner è semplicemente un server su cui è installata l'applicazione runner di GitHub Actions. Nell'esempio di flusso di lavoro precedente è presente un runs-on: ubuntu-latest attributo all'interno del blocco di processi, che indica al flusso di lavoro che il processo verrà eseguito usando lo strumento di esecuzione ospitato in GitHub in esecuzione nell'ambiente ubuntu-latest .

Quando si tratta di strumenti di esecuzione, sono disponibili due opzioni tra cui scegliere: Strumenti di esecuzione ospitati da GitHub e strumenti di esecuzione self-hosted. Se si usa uno strumento di esecuzione ospitato in GitHub, ogni processo viene eseguito in una nuova istanza di un ambiente virtuale. Il tipo di strumento di esecuzione ospitato in GitHub che definisci runs-on: {operating system-version} specifica quindi tale ambiente. Con gli strumenti di esecuzione self-hosted, è necessario invece applicare l'etichetta self-hosted e specificare il sistema operativo e l'architettura di sistema. Ad esempio, un runner self-hosted con un sistema operativo Linux e un'architettura ARM32 avrebbe il seguente aspetto: runs-on: [self-hosted, linux, ARM32].

Ogni tipo di strumento di esecuzione presenta dei vantaggi ma quelli ospitati da GitHub offrono un modo più semplice e rapido di eseguire i flussi di lavoro, seppur con opzioni limitate. Gli strumenti di esecuzione self-hosted rappresentano invece una soluzione altamente configurabile con cui eseguire i flussi di lavoro nell'ambiente locale personalizzato. Gli strumenti di esecuzione self-hosted possono essere eseguiti in locale o nel cloud. È anche possibile usare strumenti di esecuzione self-hosted per creare una configurazione hardware personalizzata con una maggiore potenza di elaborazione o più memoria. Questo tipo di configurazione consente di eseguire processi di grandi dimensioni, installare il software disponibile nella rete locale e scegliere un sistema operativo non offerto dagli strumenti di esecuzione ospitati da GitHub.

GitHub Actions può avere limiti di utilizzo

GitHub Actions presenta alcuni limiti di utilizzo, a seconda del piano GitHub e se il runner è ospitato da GitHub oppure self-hosted. Per altre informazioni sui limiti d'uso, vedere Limiti d'uso, fatturazione e amministrazione nella documentazione di GitHub.

GitHub ha ospitato strumenti di esecuzione più grandi

GitHub offre strumenti di esecuzione più grandi per i flussi di lavoro che richiedono più risorse. Questi strumenti di esecuzione sono ospitati in GitHub e offrono una maggiore CPU, memoria e spazio su disco rispetto agli strumenti di esecuzione standard. Sono progettati per gestire in modo efficiente flussi di lavoro a elevato utilizzo di risorse, garantendo prestazioni ottimali per le attività impegnative.

Dimensioni e etichette dei runner

I runner più grandi sono disponibili in diverse configurazioni, fornendo vCPU potenziati, RAM e storage SSD per soddisfare i diversi requisiti del flusso di lavoro. Queste configurazioni sono ideali per scenari come:

  • Compilazione di codebase di grandi dimensioni con file di origine estesi.
  • Esecuzione di suite di test complete, inclusi test di integrazione e end-to-end.
  • Elaborazione di set di dati di grandi dimensioni per l'analisi dei dati o le attività di Machine Learning.
  • Compilazione di applicazioni con dipendenze complesse o output binari di grandi dimensioni.
  • Esecuzione di simulazioni ad alte prestazioni o modellazione computazionale.
  • Esecuzione della codifica video, rendering o altri processi di elaborazione multimediale.

Per usare uno strumento di esecuzione più grande, specificare l'etichetta dello strumento di esecuzione desiderata nell'attributo runs-on del file del flusso di lavoro. Ad esempio, per usare un runner con 16 vCPU e 64 GB di RAM, impostare runs-on: ubuntu-latest-16core.

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

Questi strumenti di esecuzione più grandi mantengono la compatibilità con i flussi di lavoro esistenti includendo gli stessi strumenti preinstallati degli strumenti di esecuzione standard ubuntu-latest .

Per altre informazioni sulle dimensioni degli strumenti di esecuzione più grandi, vedere la documentazione di GitHub

Gestione di strumenti di esecuzione più grandi

GitHub offre strumenti per gestire strumenti di esecuzione di grandi dimensioni in modo efficace, garantendo un utilizzo ottimale delle risorse e la gestione dei costi. Ecco alcuni aspetti chiave della gestione di strumenti di esecuzione di grandi dimensioni:

Monitoraggio dell'utilizzo

È possibile monitorare l'utilizzo di strumenti di esecuzione di grandi dimensioni tramite la pagina di utilizzo di GitHub Actions nelle impostazioni del repository o dell'organizzazione. Questa pagina fornisce informazioni dettagliate sul numero di processi eseguiti, sul runtime totale e sui costi associati.

Gestione dell'accesso

Per controllare l'accesso a strumenti di esecuzione più grandi, è possibile configurare criteri a livello di repository o organizzazione. Questa configurazione garantisce che solo i flussi di lavoro o i team autorizzati possano utilizzare questi strumenti di esecuzione a utilizzo di risorse elevato.

Gestione costi

Gli strumenti di esecuzione più grandi comportano costi aggiuntivi in base al loro utilizzo. Per gestire i costi, prendere in considerazione i suggerimenti seguenti:

  • Usare strumenti di esecuzione più grandi solo per i flussi di lavoro che richiedono risorse elevate.
  • Ridurre il runtime ottimizzando i flussi di lavoro.
  • Monitorare regolarmente i dettagli di fatturazione per tenere traccia delle spese.

Ridimensionamento dei flussi di lavoro

Se i flussi di lavoro richiedono un uso frequente di strumenti di esecuzione di grandi dimensioni, prendere in considerazione strategie di ridimensionamento come:

  • Uso di strumenti di esecuzione self-hosted per carichi di lavoro prevedibili.
  • Suddivisione dei workflow in processi più piccoli per distribuire il carico tra gli esecutori standard.