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 на канала. Ако по-късно изтегляне на пакет или хост за удостоверяване се провали, използвайте това действително име на хост, когато оценявате политиката за прокси и заобикаляне.

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