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
Eseguire operazioni sui blob con Azure Storage Actions
Eseguire script pre e post esecuzione di un workflow di GitHub
Creare una custom property in GitHub
Cancellare una run di un workflow di GitHub
Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
Triggerare una pipeline su un altro repository di Azure DevOps
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Miglioramenti agli screen reader e al contrasto in Angular
Configurare il nome della run di un workflow di GitHub in base al contesto di esecuzione
Usare un KeyedService di default in ASP.NET Core 8
Utilizzare Azure Cosmos DB con i vettori