Tutte le pipeline che andiamo a creare all'interno di Azure DevOps hanno chiaramente durata differente in base al numero e alla complessità degli step che contengono per realizzare un determinato obiettivo predisposto dalla pipeline stessa. Azure DevOps applica alcuni meccanismi di protezione che impediscono ai task di essere eseguiti troppo a lungo: infatti, superati i limiti di default, i task verranno automaticamente cancellati dal servizio per evitare di incorrere in problemi come costi esagerati, per quanto riguarda i consumi su hosted-agents, piuttosto che servizi in stallo su agent di tipo self-hosted.
Il timeout, ovvero il tempo massimo di esecuzione per i task prima che Azure DevOps inizi la cancellazione (a partire da quando il job viene eseguito, non messo in coda), se non impostato a livello di job, come vedremo a breve, è fissato a 60 minuti. Se viene impostato al valore zero, però, non significa che i task verranno subito cancellati ma, anzi, avrà un valore differente in base alla tipologia di agent che stiamo referenziando dal job stesso. Esso assumerà una durata di:
- 6 ore per hosted-agent che sono associati a progetti/repository pubblici;
- 60 minuti per hosted-agents che sono associati a progetti/repository privati (se non si è pagato per una capacity differente);
- illimitata su agent self-hosted;
Per poter modificare il valore di default, a livello di pipeline YAML non dovremo fare altro che impostare la proprietà timeoutInMinutes impostandola al valore desiredato:
jobs: - job: Test timeoutInMinutes: X cancelTimeoutInMinutes: Y
Allo stesso modo, la proprietà cancelTimeoutInMinutes andrà ad impostare un limite differente di timeout sull'esecuzione del task una volta che il precedente (o il task stesso) è stato cancellato. Supponendo, ad esempio, che il task A duri più del periodo impostato da timeoutInMinutes, Azure DevOps cercherà di terminare il task in modalità graceful ma, se questo non dovesse terminare entro il periodo indicato da cancelTimeoutInMinutes, impostato ad un periodo di default di 5 minuti, Azure DevOps effettuerà una chiusura forzata.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Rendere sticky un elemento HTML in Angular
Implementare logiche di validazione complesse nelle EditForm di Blazor
Creare una direttiva per assegnare gli stili a un controllo in Angular
Produrre e condividere una variabile tra step in una pipeline YAML di Azure DevOps
Cambiare automaticamente lo stato di un work item in una pipeline di Azure DevOps
Creare layout consistenti grazie al Visual Material in Xamarin Forms
Aggiungere e rimuovere un tag ad un work item in una pipeline di Azure DevOps
C# <3 web: Blazor WebAssembly
Promuovere automaticamente un NuGet package su Azure Artifacts con Azure DevOps
Comunicazione realtime tra ASP.NET Core e Javascript con GraphQL
Creare un componente Button in Blazor per operazioni asincrone
A lap around Azure Cognitive Services
I più letti di oggi
- Modificare la modalità di esecuzione delle query con Include in Entity Framework Core 5
- Le novità di Entity Framework Core 5
- Autenticazione con JWT Token e ASP.NET Core Web API
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Creare un web server locale con LiveReload
- Effettuare l'upload di un file da Blazor su Azure Blob Storage
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Tracciabilità dei work item nel ciclo di vita del software con Azure DevOps