Un agent Azure Pipelines auto-hébergé peut contenir des règles de contournement de proxy dans un fichier .proxybypass placé dans son répertoire racine. Chaque ligne est une expression régulière ECMAScript comparée à une URL.

Par exemple, une règle pour un hôte de flux interne peut ressembler à ceci :

^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)

L'expression correspond aux URL HTTP ou HTTPS de cet hôte, avec un port numérique facultatif. La limite après le nom d'hôte évite de correspondre aussi à un nom plus long tel que packages.internal.example.other-domain.

Il s'agit du fichier de l'installation de l'agent, et non d'un fichier placé arbitrairement dans la copie de travail du code source. Sa syntaxe diffère aussi d'une valeur NO_PROXY séparée par des virgules. Copier un caractère générique de shell comme *.internal.example dans un champ d'expression régulière ne conserve pas la même signification.

Identifiez ensuite qui télécharge le paquet

Les opérations intégrées de source et d'artefact de l'agent utilisent sa configuration proxy. Les tâches peuvent récupérer les informations de proxy exposées via la bibliothèque de tâches et les appliquer à leurs propres clients HTTP.

Une tâche qui appelle un processus NuGet, dotnet ou curl externe introduit un autre consommateur. Vérifiez comment cette tâche fournit les paramètres de proxy et de contournement à l'outil. Une règle d'agent correcte ne prouve pas que chaque client de paquets indépendant l'a lue.

Conservez l'URL du flux interne dans l'enregistrement de diagnostic, y compris son schéma et son port. Testez la règle sur l'URL contactée, puis examinez la configuration de la tâche ou du client responsable de cette requête.

Articles similaires