L'uso dei template nelle pipeline YAML è obbligatorio se vogliamo riutilizzare al massimo il codice oppure estendere le pipeline per includere, ad esempio, check di compliance o security a livello di organization e così via. Quando creiamo un template, quasi sicuramente abbiamo bisogno anche di creare dei parametri per fare in modo che questo sia, appunto, riutilizzabile.
Tutti i parametri che vengono definiti in un template devono avere necessariamente un nome, un tipo e non possono essere opzionali. Proprio per questo motivo, un valore di default può essere applicati ad essi per specificarne in maniera implicita anche il tipo:
parameters: - name: pool type: string default: Azure Pipelines values: - Azure Pipelines - private-pool-1 - private-pool-2 - name: runIf displayName: Run Tests? type: boolean default: false - name: runFor type: number default: 1 steps: - script: echo 'Agent di esecuzione: ${{ parameters.pool }}' - script: echo 'Esecuzione script: ${{ parameters.runIf }}' - script: echo 'Script eseguito ${{ parameters.runFor }} volte'
Come si può vedere dall'esempio riportato sopra, abbiamo definito il tipo string per il parametro pool, a cui abbiamo poi limitato il numero di valori assegnabili alla stringa ai tre definiti nella sezione values. Quando la pipeline parte ed il template viene validato ed espanso (con la sostituzione dei parametri), la stringa verrà valutata e se non sarà valida (contenuta in quei valori proposti), allora la pipeline si fermerà immediatamente con un errore e non proseguirà nell'esecuzione.
Allo stesso modo abbiamo dichiarato anche un parametro runIf, di tipo booleano, che con i soli valori true/false, come in qualsiasi linguaggio di programmazione, ci permette di identificare rapidamente se eseguire, ad esempio, uno step oppure no. Similarmente, anche il parametro runFor, dichiarato di tipo numerico, avrà una validazione, anche se in questo caso sui numeri. Se qualche valore dovesse essere passato come stringa allora non ci sarà una conversione implicita e la pipeline terminerà con errore.
Tra i tipi supportati nella validazione troviamo string (può essere limitato ad alcuni valori di default), number (può essere limitato ad alcuni valori di default), boolean, object (per rappresentare un qualsiasi oggetto YAML), step o stepList, job o jobList, deployment o deploymentList, stage o stageList.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Ottimizzare il mapping di liste di tipi semplici con Entity Framework Core
Effettuare chiamate con versioning da Blazor ad ASP.NET Core
Creazione di componenti personalizzati in React.js con Tailwind CSS
Creare un'applicazione React e configurare Tailwind CSS
Disabilitare automaticamente un workflow di GitHub (parte 2)
Sostituire la GitHub Action di login su private registry
Mascherare l'output di un valore all'interno dei log di un workflow di GitHub
Routing statico e PreRendering in una Blazor Web App
Evitare la script injection nelle GitHub Actions
Specificare il versioning nel path degli URL in ASP.NET Web API
Sfruttare lo stream rendering per le pagine statiche di Blazor 8
Gestione degli environment per il deploy con un workflow di GitHub