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.