URL-шаблоны .proxybypass агента Azure Pipelines
Выкарыстоўвайце рэгулярныя выразы ECMAScript у каранёвым каталогу самастойна размешчанага агента Azure Pipelines і праверце ўласную інтэграцыю задачы з проксі.
Самастойна размешчаны агент Azure Pipelines можа захоўваць правілы абыходу проксі ў файле .proxybypass у сваім каранёвым каталогу. Кожны радок — гэта рэгулярны выраз ECMAScript, які супастаўляецца з URL.
Напрыклад, правіла для аднаго ўнутранага хоста канала можа выглядаць так:
^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)Выраз супастаўляе URL-адрасы HTTP або HTTPS для гэтага хоста з неабавязковым лікавым портам. Мяжа пасля імя хоста не дазваляе таксама супаставіць даўжэйшае імя, напрыклад packages.internal.example.other-domain.
Гэта файл усталёўкі агента, а не файл, які адвольна змешчаны ў копіі зыходнага кода. Яго сінтаксіс таксама адрозніваецца ад значэння NO_PROXY, падзеленага коскамі. Капіраванне сімвала-заменніка абалонкі, напрыклад *.internal.example, у поле рэгулярнага выразу не захоўвае тое ж значэнне.
Затым вызначце, хто спампоўвае пакет
Убудаваныя аперацыі агента з крыніцамі і артэфактамі выкарыстоўваюць яго канфігурацыю проксі. Задачы могуць атрымліваць адкрытую інфармацыю пра проксі праз бібліятэку задач і прымяняць яе да сваіх HTTP-кліентаў.
Задача, якая выклікае знешні працэс NuGet, dotnet або curl, дадае яшчэ аднаго спажыўца. Пераканайцеся, як гэтая задача перадае інструменту налады проксі і абыходу. Карэктнае правіла агента не даказвае, што кожны незалежны кліент пакетаў яго прачытаў.
Захоўвайце URL унутранага канала ў дыягнастычным запісе, уключаючы схему і порт. Праверце правіла на URL, да якога ідзе зварот, затым вывучыце канфігурацыю задачы або кліента, якая адказвае за гэты запыт.