En temps normal, un agent Azure Pipeline détecte automatiquement ses capacités. Cette détection à chaque lancement de l’agent. Si celui-ci est installé en tant que service, un redémarrage du service suffit pour lancer la recherche des capacités.

Contrairement à ce que j’ai déjà pu entendre, l’installation ou la suppression d’application d’un serveur de build n’entraine donc pas d’opérations manuelles complexes. Le redémarrage du serveur n’est pas requis (hormis si l’outil installé ou désinstaller le recommande).

Le problème

Mais il arrive que l’on se trouve dans une situation frustrante : un agent Windows pour ne détecte aucune capacité. Il ne remonte que quelques informations liées à son environnement (variables d’environnement, dont le PATH, nom de la machine … etc …). Mais aucun outil de build. Pas même les frameworks .net ou MsBuild.

Contrairement à ce que l‘on pourrait penser de prime abord, le problème n’est pas lié à un manque de droits du compte exécutant l’agent. Il s’agit d’un problème lié à PowerShell : l’exécution de scripts non signés est impossible sur le serveur. Malheureusement, les scripts de détections des capacités ne sont pas signés.

La solution

En temps normal, le script .cmd de configuration de l’agent effectue le travail nécessaire pour éviter ce problème. Malheureusement, ce script est limité. Si la stratégie de sécurité PowerShell change après la configuration, ou si elle est diffusée via une GPO, l’agent est incapable de fonctionner.

Pour résoudre le problème, il faut donc jouer avec la commande Set-ExecutionPolicy.

Exemple :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine

Si la commande remonte un avertissement indiquant une GPO contraire, il faut modifier la GPO (ou demander à votre gentil administrateur de la faire pour vous).