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 से अधिक की आवश्यकता हो सकती है। यदि बाद में कोई पैकेज डाउनलोड या प्रमाणीकरण होस्ट विफल हो, तो प्रॉक्सी और बायपास नीति का मूल्यांकन करते समय उसी वास्तविक होस्टनाम का उपयोग करें।

संबंधित लेख