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 भन्दा बढी आवश्यक हुन सक्छ। यदि पछिको प्याकेज डाउनलोड वा प्रमाणीकरण होस्ट असफल भयो भने, प्रोक्सी र बाइपास नीतिको मूल्याङ्कन गर्दा त्यही वास्तविक होस्टनाम प्रयोग गर्नुहोस्।

सम्बन्धित लेखहरू