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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
.NET Conference Italia 2023
Paginare i risultati con QuickGrid in Blazor
Sfruttare al massimo i topic space di Event Grid MQTT
Load test di ASP.NET Core con k6
Disabilitare automaticamente un workflow di GitHub
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
Cancellare una run di un workflow di GitHub
Effettuare il binding di date in Blazor
Usare una container image come runner di GitHub Actions
Creare form tipizzati con Angular
Utilizzare Azure AI Studio per testare i modelli AI