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
Gestire un observable quando la finestra del browser non è attiva in Angular
Disabilitare il warning sul detachedHead di git nelle pipeline YAML di Azure DevOps
Utilizzare il soft delete for Azure file share
Modificare automaticamente la Wiki da una pipeline YAML con Azure DevOps
Produrre e condividere una variabile tra step in una pipeline YAML di Azure DevOps
Abilitare Hot Module Replacement in Angular
Eseguire lo shutdown pulito di un'applicazione ASP.NET Core
Specificare un constraint per TypeParam di un componente Blazor generico
Creare automaticamente una relazione padre-figlio tra work item in Azure DevOps
Ottimizzare le dimensioni di un'applicazione .NET Core tramite il trimming
Utilizzare il Nullish Coalescing con TypeScript
Point-in-time restore con gli Azure Storage Blob
I più letti di oggi
- Docker 101
- (My) DevOps story - from failure to success
- Modificare automaticamente la Wiki da una pipeline YAML con Azure DevOps
- DevOps per le applicazioni desktop
- Welcome to Container&DevOps Day!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Gestione dei token negli input di testo con la Universal Windows Platform
- Infrastructure as Code: ARM vs Terraform
- Effettuare il redirect da HTTP a HTTPS con la Azure CDN