Самостоятелно хостван агент на Azure Pipelines може да съхранява правила за заобикаляне на прокси в файл .proxybypass в главната си директория. Всеки ред е регулярен израз на ECMAScript, съпоставян с URL.

Например правило за един вътрешен хост за емисия може да изглежда така:

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

Изразът съпоставя HTTP или HTTPS URL адреси за този хост, с незадължителен цифров порт. Границата след името на хоста не позволява да се съпостави и по-дълго име като packages.internal.example.other-domain.

Това е файл на инсталацията на агента, а не файл, поставен произволно в копието на изходния код. Синтаксисът му също се различава от стойност NO_PROXY, разделена със запетаи. Копирането на shell заместител като *.internal.example в поле за регулярен израз не запазва същото значение.

След това установете кой изтегля пакета

Вградените операции на агента с източници и артефакти използват неговата прокси конфигурация. Задачите могат да получат разкритата прокси информация чрез библиотеката за задачи и да я приложат към своите HTTP клиенти.

Задача, която извиква външен процес NuGet, dotnet или curl, въвежда още един потребител. Проверете как тази задача подава прокси и настройки за заобикаляне на инструмента. Правилно правило на агента не доказва, че всеки независим клиент за пакети го е прочел.

Пазете URL адреса на вътрешната емисия в диагностичния запис, включително схемата и порта. Тествайте правилото срещу URL адреса, който се посещава, след което прегледайте конфигурацията на задачата или клиента, отговорна за тази заявка.

Подобни статии