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
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow
Recuperare l'ultima versione di una release di GitHub
Disabilitare le run concorrenti di una pipeline di Azure DevOps
Gestione degli stili CSS con le regole @layer
Loggare le query più lente con Entity Framework
Gestire gli accessi con Token su Azure Container Registry
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Disabilitare automaticamente un workflow di GitHub (parte 2)
Proteggere le risorse Azure con private link e private endpoints
Aprire una finestra di dialogo per selezionare una directory in WPF e .NET 8
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
Generare la software bill of material (SBOM) in GitHub