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 पेक्षा अधिक आवश्यक असू शकते. जर नंतरचे पॅकेज डाउनलोड किंवा प्रमाणीकरण होस्ट अयशस्वी झाले, तर प्रॉक्सी आणि बायपास धोरणाचे मूल्यांकन करताना तेच प्रत्यक्ष होस्टनाव वापरा.

संबंधित लेख