Nell'ottica di semplificare i processi e condividere il più possibile il codice per riutilizzarlo in altri scenari, nascono i re-usable workflow in GitHub, che sono particolarmente utili quando la nostra applicazione è distribuita su più repository. Per esempio, quando sviluppiamo un prodotto basato a microservizi, avremo circa le stesse automazioni per fare le build e release su tutti i repository che formano l'applicazione vera e propria, per cui diventa fondamentale riciclare più codice possibile e ridurre al minimo il rischio di errori.
Supponendo di essere in un repository di un microservizio, possiamo invocare il workflow semplicemente puntando al suo "link" interno a GitHub stesso.
name: My workflow on: pull_request: types: [opened, reopened, edited, synchronize] push: branches: [main] workflow_dispatch: jobs: my-job: uses: my-org/my-reusable-workflow-repository/.github/workflows/my-shared-workflow.yml@main with: name: Matteo
Come si può notare, sembra un normalissimo workflow di GitHub, inclusa la configurazione iniziale con i trigger. Di fatto, non cambia proprio nulla, se non il job che, anzichè essere "riempito" con delle GitHub Action, è composto solo da un puntatore al workflow condiviso che si trova su un altro repository.
Se andiamo nel repository che contiene i workflow da condividere (che abbiamo chiamato my-reusable-workflow-repository nell'esempio sopra), possiamo costruire la pipeline come se fosse un altro "normale" workflow di GitHub.
name: My reusable workflow on: workflow_call: inputs: name: description: 'The name of the person to greet' required: true type: string jobs: my-job: runs-on: ubuntu-latest steps: - name: Print hello run: echo "Hello, ${{ inputs.name }}" shell: bash
In questo caso quello che cambia è solo il trigger, diventato workflow_call. Di fatto, quando viene invocato, vengono passati tutti i parametri richiesti in input e viene eseguito il flusso indicato dal (uno o più) job.
Questo sistema di re-usable workflow ha qualche limitazione, tra cui il fatto che il repository che contiene i workflow da condividere deve essere visibile (public o internal) e non si possono innestare più di 20 livelli di condivisione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Disabilitare automaticamente un workflow di GitHub (parte 2)
Gestire i dati con Azure Cosmos DB Data Explorer
Sfruttare gli embedding e la ricerca vettoriale con Azure SQL Database
.NET Conference Italia 2024
Cancellare una run di un workflow di GitHub
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow
Miglioramenti nell'accessibilità con Angular CDK
Eseguire operazioni sui blob con Azure Storage Actions
Disabilitare automaticamente un workflow di GitHub
Ottenere un token di accesso per una GitHub App
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
Bloccare l'esecuzione di un pod in mancanza di un'artifact attestation di GitHub