I benefici nell'uso di YAML per descrivere le nostre pipeline li abbiamo già discussi più volte e fra questi figurano, ad esempio, il supporto al versionamento, piuttosto che la possibilità di riutilizzare determinati pezzi di codice della pipeline stessa per creare dei template.
Ogni template è rappresentato da un file YAML separato dalla pipeline, che verrà poi incluso successivamente tramite l'attributo template e, se necessario, può contenere al suo interno uno o più parametri che servono a rendere lo script generico. Supponiamo di avere, come nel caso seguente, un template che è in grado di effettuare la build di Visual Studio di una nostra solution:
parameters: - name: 'solution' default: '' type: string steps: - task: msbuild@1 inputs: solution: ${{ parameters.solution }} - task: vstest@2 inputs: solution: ${{ parameters.solution }}
Chiaramente questo script deve essere flessibile poiché, sia la fase di build che quella di test, possono funzionare con un qualsiasi file di solution (.sln) o qualsiasi file di progetto (ad esempio .csproj). Per risolvere a questa esigenza, infatti, il parametro solution è stato aggiunto al template e quindi passato a tutti i task, come msbuild e vstest, che lo necessitano per diventare riutilizzabili con qualsiasi progetto.
Cosa succede però nel caso in cui il parametro non viene passato e quindi prende il valore di default di stringa vuota, come specificato nel template? La risposta in questo caso è semplice, il task di build fallirà. In altri casi, quello che vogliamo è però un controllo di validità dei parametri di ingresso al template e, di conseguenza, far fallire l'intera pipeline se non rispettano determinate caratteristiche.
Per fare sì che la build fallisca se manca un template, possiamo semplicemente aggiungere un task di tipo bash (o PowerShell, in base alle esigenze), per verificare il valore del parametro di ingrasso, rimappato come variabile d'ambiente:
- bash: | if [ -z "$SOLUTION" ]; then echo "##vso[task.logissue type=error;]Missing template parameter \"solution\"" echo "##vso[task.complete result=Failed;]" fi env: SOLUTION: ${{ parameters.solution }} displayName: Check for required parameters
La build poi viene fatta fallire in caso in cui il parametro sia ancora una stringa vuota semplicemente impostando il valore della variabile complete come Failed. Questo è diverso rispetto a quanto avveniva prima, poiché in questo caso siamo noi a poter specificare il messaggio di errore, più naturale da comprendere guardando i log di sistema al termine dell'esecuzione della build.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eliminare una project wiki di Azure DevOps
Eseguire i worklow di GitHub su runner potenziati
Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
Applicare un filtro per recuperare alcune issue di GitHub
Cancellare una run di un workflow di GitHub
Gestione file Javascript in Blazor con .NET 9
Creare un webhook in Azure DevOps
Gestione CSS in Blazor con .NET 9
Creare una libreria CSS universale: Clip-path
Introduzione alle Container Queries