Самостійно розміщений агент 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, до якого йде звернення, потім вивчіть конфігурацію завдання або клієнта, відповідальну за цей запит.

Схожі статті