URL шаблони в .proxybypass на агента на Azure Pipelines
Използвайте регулярни изрази на ECMAScript в главната директория на самостоятелно хоствания агент на Azure Pipelines и проверете собствената прокси интеграция на задачата.
Самостоятелно хостван агент на 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 адреса, който се посещава, след което прегледайте конфигурацията на задачата или клиента, отговорна за тази заявка.