Uno dei primi argomenti che dobbiamo affrontare, quando progettiamo una nuova pipeline, è la scelta dall'agent giusto. Infatti, non è detto che tutti gli step e gli automatismi che andremo a definire gireranno indifferentemente su tutti gli agent: potrebbe essere certamente uno scenario possible ma, talvolta, potremmo avere delle dipendenze da Windows (es. per compilare un'app .NET Framework), piuttosto che da macOS (es. per creare un'app per iOS).
L'impostazione dell'agent viene specificata tramite la property pool e può essere fatta globalmente su tutta la pipeline, per specificarne uno di default, piuttosto che per ogni stage o job, in modo più selettivo:
pool: vmImage: 'windows-latest'
Come si può intuire dal nome della property e dal codice di esempio, però, non stiamo specificando solo l'agent, ma direttamente tutto il pool. In questo caso, significa che prenderemo in considerazione il primo fra tutti gli agent disponibili (in base al livello di parallelismo) dal pool di macchine chiamato 'windows-latest' (ovvero le hosted VM di Microsoft con l'ultima versione di Windows).
Tuttavia, le hosted VM hanno software pre-installato da Microsoft e, quindi, potrebbero non servirci nel caso in cui ci fosse la necessità di software custom. In questo scenario, l'IT avrà configurato un pool di macchine self-hosted, che conterrà N macchine pronte ad essere utilizzate per eseguire la pipeline. Per supportare un pool self-hosted, dobbiamo modificare il codice precedente in:
pool: name: 'MyPool'
All'interno del pool di macchine, però, potrebbero esserci configurate VM Windows, Linux, macOS o altro ancora. Come anticipato, però, non è detto che la nostra pipeline possa girare ovunque e quindi abbiamo bisogno di impostare delle specifiche, ovvero le demands, per fare in modo che la pipeline cerchi il primo agent disponibile con le caratteristiche che noi ricerchiamo:
pool: name: 'MyPool' demands: - agent.os -equals Windows - Preview
La definizione delle capability può essere fatta direttamente dai setting di progetto/organizzazione, selezionando il pool e quindi i singoli agent:

Nell'esempio stiamo andando a filtrare tutte le macchine del pool MyPool, prendendo solo quelle che hanno Windows come sistema operativo e, tra queste, quelle che hanno anche la capability Preview (senza controllare il suo valore). Quando la pipeline partirà, in base alle opzioni di parallelismo impostate e in base al numero di macchine disponibili con la configurazione applicata, verrà associato un agent corrispondente alla richiesta e quindi saremo piuttosto sicuri che la pipeline girerà correttamente.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Popolare una classe a partire dal testo, con Semantic Kernel e ASP.NET Core Web API
Cancellare una run di un workflow di GitHub
Creare un webhook in Azure DevOps
Eliminare una project wiki di Azure DevOps
Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
Bloccare l'esecuzione di un pod in mancanza di un'artifact attestation di GitHub
Utilizzare DeepSeek R1 con Azure AI
Eseguire i worklow di GitHub su runner potenziati
Gestire eccezioni nei plugin di Semantic Kernel in ASP.NET Core Web API
Ottimizzazione dei block template in Angular 17
Recuperare App Service cancellati su Azure