In alcuni casi, come quello che vedremo oggi, può essere necessario poter continuare oltre l'esecuzione di un passaggio nella pipeline, anche in caso questo fallisca, per poter prendere delle determinate azioni di gestione dell'errore/problematica - un po' come se fossimo in un blocco try-catch in C# - e rimandare l'errore più avanti per, ad esempio, terminare l'esecuzione del workflow.

Nell'esempio qui sotto, vediamo proprio un caso in cui l'esecuzione deve per forza di cose continuare. Il primo degli step riguarda l'esecuzione degli unit test di un progetto. Questo passaggio potrebbe sicuramente essere marcato come 'succeeded', nel caso in cui tutti i test siano passati con successo, ma, in alternativa, potrebbe fallire per diverse condizioni. Per citarne qualcuna, in un caso potrebbe fallire perchè almeno un test non è passato, oppure perchè non si è raggiunta la soglia minima dell'80% di code coverage.

steps:
  - name: Run tests
    shell: pwsh
    id: tests
    continue-on-error: true
    run: dotnet test --no-restore /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura /p:Threshold=80
    
  # TODO: missing code coverage reporting

  - name: Fail if tests failed
    shell: bash
    if: steps.tests.outcome != 'success'
    run: exit 1

Indipendentemente dall'errore, io voglio poter continuare l'esecuzione della pipeline, almeno temporaneamente, per poter generare la reportistica sullo stato degli unit test che ho messo in esecuzione, così che sia più facile individuare ciò che è andato storto e porne rimedio. Per questo motivo, lo step viene marcato con la property continue-on-error.

Abbiamo così gestito temporaneamente l'errore. Tuttavia, non ha più senso continuare l'esecuzione del workflow e, ad esempio, portare l'applicazione nell'ambiente di produzione, poichè qualcosa non è andato a buon fine e, quindi, vogliamo comunque far fallire la pipeline una volta che la reportistica è disponibile (ad esempio in un commento sulla pull request, piuttosto che con un artifact sul workflow stesso).

Per far fallire il workflow, aggiungiamo semplicemente uno step in fondo a tutto, che non farà altro che terminare l'esecuzione con un exit code diverso da zero (così che indichi un errore), solo nel caso in cui lo step degli unit test non si è completato con successo. Nel caso in cui, invece, tutti i test siano passati e c'è sufficiente copertura del codice sorgente, allora lo step di failure non verrà invocato e il workflow continuerà la sua esecuzione.