Tutte le pipeline che andiamo a costruire, hanno dei riferimenti a determinate variabili: che siano i valori passati ai task di sistema, piuttosto che i parametri passati ai template, piuttosto che quelle definite a livello globale, rappresentano l'unico sistema che abbiamo per poter riutilizzare la pipeline in modo tale da avere lo stesso comportamento, ma un risultato diverso, personalizzato, in base a quanto specificato, appunto, dalle variabili.
Le variabili, però, non è detto che siano solamente definite a livello globale. Di fatto, potremmo trovarci nel caso in cui l'output di un task sia utile come input di un successivo, creando una dipendenza tra i due. Per fare un esempio banale, ci potrebbe essere un task A in grado di creare un servizio web e un task B che, per caricare un progetto web al suo interno, ha bisogno di sapere l'endpoint prodotto dal task A.
steps: - script: | # Creazione del sito web, omessa... # Pubblicazione della variabile con l'endpoint $url = "https://aspitalia.com" echo "##vso[task.setvariable variable=websiteUrl]$url"
Come possiamo vedere dall'esempio, è possibile creare una variabile all'interno di un task tramite la direttiva ##vso a cui viene passata l'impostazione task.setvariable. Da qui, possiamo andare ad impostare il nome e di conseguenza il valore della variabile, scrivendola come se fosse una chiamata allo stream di output sulla console, che verrà poi letta da un secondo task:
- bash: echo il mio url è $(websiteUrl) - bash: echo "il sito web è $WEBSITEURL" - pwsh: Write-Host "Il sito web è $env:WEBSITEURL"
L'esempio mostra le diverse modalità di utilizzo della variabile websiteUrl in un task B, prodotta da un task A, sua diretta dipendenza. E' bene far notare che questa variabile, per come è stata costruita, sarà disponibile solamente agli step successivi alla sua generazione e non sarà visibile ad altri job o ad altri stage: per estendere la sua visibilità abbiamo bisogno di applicare determinati accorgimenti che approfondiremo nei prossimi script su questo canale.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Creare azioni rapide con SwipeView in Xamarin Forms
Rendering di raw HTML in Blazor
Tracciare il body delle richieste fallite con Application Insights in .NET Core
Eseguire una chiamata asincrona durante la validazione di una form in Blazor
DevOps for any developer with GitHub
Web capabilities AKA project Fugu
Utilizzare il Nullish Coalescing con TypeScript
Introduzione a GitHub
Abilitare la scrittura multi-pointer con InkCanvas nella Universal Windows Platform
Torniamo con i nostri live streaming il 10/06 con ReBuild 2020: tutte le novità di #MSBuild in un solo pomeriggio.Parleremo di #net5, #aspnet5, #ef5, #azure, #devops, #iot e tanto altro ancora! Agenda online a metà maggio, iscrizioni già aperte => https://aspit.co/ReBuild-20
Cambiare automaticamente lo stato di un work item in una pipeline di Azure DevOps
Taggare automaticamente un team member in work item tramite Azure DevOps
I più letti di oggi
- Modificare la modalità di esecuzione delle query con Include in Entity Framework Core 5
- Le novità di Entity Framework Core 5
- Autenticazione con JWT Token e ASP.NET Core Web API
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Creare un web server locale con LiveReload
- Effettuare l'upload di un file da Blazor su Azure Blob Storage
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Tracciabilità dei work item nel ciclo di vita del software con Azure DevOps