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
Implementare il throttling in ASP.NET Core
Trasformare qualsiasi backend in un servizio GraphQL con Azure API Management
Implementare l'infinite scroll con QuickGrid in Blazor Server
Copiare automaticamente le secret tra più repository di GitHub
Verificare la provenienza di un commit tramite le GitHub Actions
Eseguire attività basate su eventi con Azure Container Jobs
Miglioramenti nell'accessibilità con Angular CDK
Disabilitare automaticamente un workflow di GitHub (parte 2)
Configurare policy CORS in Azure Container Apps
Ottimizzare il mapping di liste di tipi semplici con Entity Framework Core
Evitare la command injection in un workflow di GitHub
I più letti di oggi
- C# 4
- Spaziatura tra i caratteri in Silverlight 5
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Segui in tempo reale il TechEd 2004
- da oggi è possibile fare login velocemente con LinkedIn e Google. a questi si aggiunge il supporto già attivo per Facebook, Twitter, Microsoft Account, Windows Hello e OpenID, per darvi sempre più possibilità di accedere semplicemente alla nostra community! #aspitalia
- Migrare una service connection a workload identity federation in Azure DevOps
- Evitare postback multipli in un UpdatePanel