NuGetAuthenticate налаштовує автентифікацію для каналів пакетів. Успішне завдання автентифікації не налаштовує вихідний проксі для dotnet, nuget.exe чи MSBuild.

Якщо налаштування облікових даних успішне, а наступному restore потрібен HTTP-проксі, надайте середовище цього процесу. Наприклад:

- task: NuGetAuthenticate@1

- script: dotnet restore
  env:
    http_proxy: $(proxyUrl)
    no_proxy: packages.corp.example,localhost,127.0.0.1

proxyUrl — наявна змінна конвеєра, що містить потрібний повний URL проксі. Налаштуйте список обходу відповідно до фактичної політики маршрутизації каналів. Для публічних каналів, дозволених через публічний посередник, список HTTP-проксі дає кандидатів для proxyUrl без облікового запису; обходи приватних каналів залиште на місці. Цей фрагмент припускає, що джерела пакетів проєкту вже налаштовані.

У Linux і macOS задокументовані назви середовища пишуться малими літерами. Змінна конвеєра з назвою http_proxy може стати великими літерами під час автоматичного експорту. Явне зіставлення env зберігає ключ, потрібний інструменту.

Для агента, який ви розміщуєте самостійно, інший варіант — задати ці значення в середовищі процесу агента й перезапустити агент після зміни. Середовище іншого термінала не оновлює вже запущену службу.

NuGet також підтримує записи проксі у своїй конфігурації. Тримайте їх окремо від облікових даних джерел пакетів і перевіряйте фактичну область дії конфігурації, коли restore виконується під іншим обліковим записом.

Відновленому пакету може знадобитися більше, ніж перший URL каналу. Якщо подальше завантаження пакета або вузол автентифікації не працює, використовуйте це фактичне ім’я вузла під час оцінювання політики проксі та обходу.

Схожі статті