Un agente Azure Pipelines self-hosted può contenere regole di bypass del proxy in un file .proxybypass nella propria directory radice. Ogni riga è un'espressione regolare ECMAScript confrontata con un URL.

Ad esempio, una regola per un host di feed interno può avere questo aspetto:

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

L'espressione corrisponde agli URL HTTP o HTTPS di quell'host, con una porta numerica opzionale. Il confine dopo il nome dell'host evita di corrispondere anche a un nome più lungo come packages.internal.example.other-domain.

Questo è il file dell'installazione dell'agente, non un file inserito arbitrariamente nella copia di lavoro del codice sorgente. La sua sintassi differisce anche da un valore NO_PROXY separato da virgole. Copiare un carattere jolly della shell come *.internal.example in un campo di espressione regolare non conserva lo stesso significato.

Poi identificate chi scarica il pacchetto

Le operazioni integrate di origine e artefatto dell'agente usano la sua configurazione proxy. Le attività possono recuperare le informazioni proxy esposte tramite la libreria delle attività e applicarle ai propri client HTTP.

Un'attività che richiama un processo NuGet, dotnet o curl esterno introduce un altro consumatore. Verificate come tale attività fornisce allo strumento le impostazioni proxy e di bypass. Una regola dell'agente corretta non dimostra che ogni client di pacchetti indipendente l'abbia letta.

Conservate l'URL del feed interno nel record diagnostico, inclusi schema e porta. Provate la regola sull'URL con cui si comunica, poi esaminate la configurazione dell'attività o del client responsabile di quella richiesta.

Articoli correlati