DevOps Bootcamp · Lezione

Workflow tra repository

Impari a concatenare workflow tra repository diversi per gestire le dipendenze e orchestrare deploy complessi.

Workflow tra repository è una lezione DevOps Bootcamp gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento DevOps Bootcamp, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso DevOps Bootcamp include 4 lezioni in totale.

Introduzione ai workflow tra repository

Nello sviluppo software moderno, le applicazioni sono spesso composte da più componenti distribuiti in repository diversi. Si pensi ai microservizi, alle librerie condivise o alle configurazioni di distribuzione separate.

Orchestrare i workflow tra questi repository distinti consente una maggiore modularità e una migliore separazione delle responsabilità. In questa lezione vedrà come ottenere questo risultato con GitHub Actions.

Perché orchestrare repository diversi?

Tradizionalmente, i workflow di GitHub Actions sono limitati a un singolo repository. Ma cosa succede se è necessario:

Creare un artefatto in un repository e attivare una distribuzione in un altro?
Avere un repository di configurazione condivisa che attivi aggiornamenti in più repository di servizi?
Applicare in tutti gli altri repository le policy di sicurezza gestite in un repository centrale?

I workflow tra repository offrono una soluzione per questi scenari complessi.

Connettere i repository: `repository_dispatch`

GitHub Actions offre un tipo di evento speciale chiamato repository_dispatch. Funziona come un webhook personalizzato per i repository GitHub.

Un workflow (il 'mittente') invia una richiesta API a GitHub.
Un altro workflow (il 'destinatario') in un repository diverso è in ascolto di questo evento specifico.

Questo consente di attivare programmaticamente workflow in repository diversi.

Configurare il workflow destinatario

Per ricevere un evento repository_dispatch, è necessario configurare un workflow nel repository di destinazione affinché sia in ascolto di questo evento. A tale scopo si usa la parola chiave on:.

Ecco come potrebbe essere il workflow nel repository repo-B:

name: Receive Dispatch Event

on:
  repository_dispatch:
    types: [my-custom-event]

jobs:
  process-event:
    runs-on: ubuntu-latest
    steps:
      - name: Log event payload
        run: |
          echo "Event type: ${{ github.event.action }}"
          echo "Payload: ${{ toJSON(github.event.client_payload) }}"

Comprendere la configurazione del destinatario

Nell'esempio precedente:

on: repository_dispatch: indica a GitHub di restare in ascolto di questo evento.
types: [my-custom-event] specifica che questo workflow verrà eseguito solo se l'evento inviato è di tipo my-custom-event. È possibile definire più tipi.
github.event.action conterrà il tipo di evento, ad esempio my-custom-event.
github.event.client_payload contiene eventuali dati personalizzati inviati con il dispatch.

Attivazione dell'evento: invio da un altro repository

Per attivare un evento repository_dispatch, è necessario effettuare una richiesta HTTP POST all'API di GitHub. È possibile farlo usando curl o GitHub CLI (gh cli) dall'interno di un altro workflow di GitHub Actions o di uno script.

Requisiti principali:

Il proprietario e il nome del repository di destinazione.
Un type di evento in ascolto nel workflow ricevente.
Un client_payload per eventuali dati personalizzati.
Un token di accesso personale GitHub (PAT) con ambito repo.

Esempio: invio con `gh cli`

Ecco un workflow in repo-A che invia un evento a repo-B. Noti come utilizziamo un secret per il token e passiamo un client_payload.

name: Trigger Deploy Workflow

on:
  push:
    branches: [main]

jobs:
  dispatch:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install GitHub CLI
        run: sudo apt-get update && sudo apt-get install gh -y

      - name: Dispatch event to repo-B
        env:
          GH_TOKEN: ${{ secrets.CROSS_REPO_PAT }}
        run: |
          gh api \
            --method POST \
            -H "Accept: application/vnd.github.v3+json" \
            /repos/YOUR_ORG/repo-B/dispatches \
            -f event_type='my-custom-event' \
            -f client_payload='{"ref":"${{ github.ref }}", "sha":"${{ github.sha }}"}'

Protezione dell'accesso tra repository

Il GITHUB_TOKEN predefinito fornito a un workflow è limitato al repository in cui viene eseguito il workflow. Per attivare eventi in *un altro* repository, è necessario un token con autorizzazioni più ampie.

Utilizzi un Personal Access Token (PAT) con ambito repo.
Salvi questo PAT come repository secret (ad esempio, CROSS_REPO_PAT) nel repository che attiva l'evento.
Non inserisca mai i PAT direttamente nei file di workflow.

Passaggio di dati personalizzati con `client_payload`

Il client_payload è un oggetto JSON che è possibile includere quando si invia un evento. È fondamentale per passare il contesto o i dati dal workflow che attiva l'evento a quello che lo riceve.

Esempi di dati che è possibile passare:

Lo SHA del commit o il nome del branch che ha attivato la compilazione.
Un ambiente di destinazione (ad esempio, "staging", "production").
Il numero di versione di un artifact da distribuire.

Ricordi: client_payload è visibile nei log del workflow, quindi eviti di inserirvi informazioni sensibili.

Verifica rapida sui workflow tra repository

Ha imparato a orchestrare workflow tra diversi repository GitHub. Verifichiamo ora la sua comprensione dei componenti principali.

Riepilogo: orchestrazione tra repository

Ha imparato con successo a implementare workflow tra repository usando repository_dispatch!

Perché: per gestire le dipendenze e orchestrare distribuzioni complesse tra più repository.
Come: un workflow «mittente» effettua una chiamata API a GitHub, attivando un workflow «ricevente» in un altro repository.
Elemento chiave: il tipo di evento repository_dispatch e i types corrispondenti nel workflow ricevente.
Dati: utilizzi client_payload per passare informazioni non sensibili tra i workflow.
Sicurezza: utilizzi sempre un PAT con ambito repo, archiviato come secret, per l'accesso tra repository.

Questa potente funzionalità consente di creare pipeline CI/CD altamente flessibili e disaccoppiate.

Domande Frequenti

La lezione «Workflow tra repository» è gratuita?

Sì — il testo completo di «Workflow tra repository» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso DevOps Bootcamp, passa a CoddyKit PRO. Il corso DevOps Bootcamp include 4 lezioni in totale.

Cosa imparerò in «Workflow tra repository»?

Impari a concatenare workflow tra repository diversi per gestire le dipendenze e orchestrare deploy complessi. Eserciti DevOps Bootcamp con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare DevOps Bootcamp?

Non è richiesta alcuna esperienza precedente. DevOps Bootcamp su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.

Quanto tempo richiede la lezione «Workflow tra repository»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione DevOps Bootcamp?

Sì. Ogni lezione DevOps Bootcamp include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

← Torna a DevOps Bootcamp