Azure Pipelines: NuGet Restore માટે પ્રોક્સી એન્વાયર્નમેન્ટ સેટ કરો

NuGetAuthenticate એ ફીડ ક્રેડેન્શિયલ પહેલેથી ગોઠવ્યાં હોય તો પણ restore પ્રક્રિયાને http_proxy અને no_proxy આપો.

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 કરતાં વધુની જરૂર પડી શકે. જો પછીનું પેકેજ ડાઉનલોડ કે પ્રમાણીકરણ હોસ્ટ નિષ્ફળ જાય, તો પ્રોક્સી અને બાયપાસ ધોરણનું મૂલ્યાંકન કરતી વખતે તે વાસ્તવિક હોસ્ટનામ વાપરો.

સંબંધિત લેખો