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
Cancellare una run di un workflow di GitHub
Eseguire script pre e post esecuzione di un workflow di GitHub
Ottimizzare la latenza in Blazor 8 tramite InteractiveAuto render mode
Utilizzare un service principal per accedere a Azure Container Registry
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow
Eseguire query verso tipi non mappati in Entity Framework Core
Creare un webhook in Azure DevOps
Migrare una service connection a workload identity federation in Azure DevOps
Sostituire la GitHub Action di login su private registry
Configurare il nome della run di un workflow di GitHub in base al contesto di esecuzione
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Eseguire una ricerca avanzata per recuperare le issue di GitHub