Disegnando le pipeline per, ad esempio, automatizzare la compilazione ed il rilascio delle nostre applicazioni, ci può capitare di dover riflettere su quale strategia adottare nel caso in cui si debbano incontrare dei vincoli: come abbiamo già visto in passato, una strategia efficace può essere quella di effettuare una determinata operazione tramite il comando if, se il comportamento positivo/negativo è determinabile a "compile-time", mentre in altri casi dobbiamo deciderlo a "run-time" tramite l'uso delle condizioni (condition).
Facendo un esempio concreto, supponiamo di avere i repository A e B. Entrambi contengono un'applicazione .NET Core e fanno uso di un template che compila e distribuisce l'applicazione. Tuttavia, la differenza consiste nel fatto che in A abbiamo un file global.json utile per specificare una versione precisa dell'SDK da utilizzare per compilare l'app stessa. Per il repository B, questa specifica non è necessaria e può andare bene compilare con l'ultima versione (o una di default) disponibile.
Per fare in modo che il template possa gestire entrambe le casistiche, dato che il comportamento non è determinabile a compile-time poichè i repository non sono ancora stati recuperati, possiamo seguire due strade: la prima prevede una piccola ricerca del file global.json all'interno del repository, mentre la seconda, probabilmente più facile, consiste nell'installare prima la versione specificata dal global.json e, di conseguenza, procedere all'installazione dell'SDK di default nel caso in cui non sia stato trovato:
- task: UseDotNet@2 displayName: 'Use .NET Core SDK (global.json)' continueOnError: true inputs: packageType: 'sdk' useGlobalJson: true - task: UseDotNet@2 displayName: 'Use .NET Core SDK (default)' condition: eq(variables['Agent.JobStatus'], 'SucceededWithIssues') inputs: packageType: sdk version: 3.1.100 installationPath: $(Agent.ToolsDirectory)/dotnet
Come si può vedere dall'esempio, abbiamo dovuto ricorrere a due "trucchi": il primo consiste nell'applicare l'attributo continueOnError che indica alla pipeline che in caso di errore (ovvero global.json non trovato) deve continuare l'esecuzione e non fermarsi immediatamente, mentre il secondo è rappresentato dalla condizione del secondo task, che va a controllare lo stato del job attualmente in esecuzione. Infatti, se lo stato del job risulta del tipo 'SucceededWithIssues', allora siamo sicuri che il task precedente è fallito e dobbiamo procedere nell'installazione dell'SDK di default.
Questo approccio può non essere il migliore. Infatti, sebbene funzioni perfettamente, dobbiamo tenere in considerazione il fatto che verrà perso un po' di tempo durante l'esecuzione del task che prova a fare la prima installazione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Triggerare una pipeline su un altro repository di Azure DevOps
Fissare una versione dell'agent nelle pipeline di Azure DevOps
Ottenere un token di accesso per una GitHub App
.NET Aspire per applicazioni distribuite
Anonimizzare i dati sensibili nei log di Azure Front Door
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
Rendere i propri workflow e le GitHub Action utilizzate più sicure
Ordine e importanza per @layer in CSS
Eseguire una ricerca avanzata per recuperare le issue di GitHub
Gestione CSS in Blazor con .NET 9
Ottimizzare le performance usando Span<T> e il metodo Split
Migliorare i tempi di risposta di GPT tramite lo streaming endpoint in ASP.NET Core
I più letti di oggi
- Sfruttare i nuovi overload di TimeSpan.From* per creare timespan usando numeri interi
- Documentare i servizi REST con Swagger e OpenAPI con .NET 9
- Inviare i comandi SQL generati da Entity Framework alla console di Visual Studio
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Gestione CSS in Blazor con .NET 9
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!