Controllare i parametri di ingresso in un template di una pipeline di Azure DevOps

di Matteo Tumiati, in DevOps,

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

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti

I più letti di oggi