Azure Pipelines: наладзіць проксі-асяроддзе для NuGet Restore

Забяспечце працэс restore значэннямі http_proxy і no_proxy, нават калі NuGetAuthenticate ужо наладзіў уліковыя даныя для каналаў.

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 канала. Калі позняе спампоўванне пакета або хост аўтэнтыфікацыі не спрацуе, выкарыстоўвайце гэтае фактычнае імя хоста пры ацэнцы палітыкі проксі і абыходу.

Падобныя артыкулы