NuGetAuthenticate configure l’authentification auprès des flux de paquets. Une tâche d’authentification réussie ne configure pas le proxy sortant pour dotnet, nuget.exe ni MSBuild.

Si la configuration des identifiants réussit et que la restauration suivante a besoin d’un proxy HTTP, fournissez l’environnement de ce processus. Par exemple :

- task: NuGetAuthenticate@1

- script: dotnet restore
  env:
    http_proxy: $(proxyUrl)
    no_proxy: packages.corp.example,localhost,127.0.0.1

proxyUrl est une variable de pipeline existante qui contient l’URL complète du proxy souhaitée. Adaptez la liste d’exclusion à la politique de routage réelle des flux. Pour les flux publics autorisés via un intermédiaire public, la liste de proxys HTTP fournit des candidats pour un proxyUrl sans compte ; conservez les exclusions des flux privés. Cet extrait suppose que les sources de paquets du projet sont déjà configurées.

Sous Linux et macOS, les noms d’environnement documentés sont en minuscules. Une variable de pipeline nommée http_proxy peut passer en majuscules lors de l’export automatique. Un mappage explicite d’env conserve la clé dont l’outil a besoin.

Pour un agent auto-hébergé, une autre option consiste à définir ces valeurs dans l’environnement du processus de l’agent et à redémarrer cet agent après modification. L’environnement d’un autre terminal ne met pas à jour un service déjà en cours d’exécution.

NuGet prend également en charge des entrées de proxy dans sa configuration. Gardez-les séparées des identifiants des sources de paquets et vérifiez la portée effective de la configuration lorsqu’une restauration s’exécute sous un autre compte.

Un paquet restauré peut nécessiter plus que la première URL du flux. Si un téléchargement de paquet ultérieur ou un hôte d’authentification échoue, utilisez ce nom d’hôte réel pour évaluer la politique de proxy et d’exclusion.

Articles similaires