स्व-होस्ट केलेला Azure Pipelines एजंट त्याच्या रूट डिरेक्टरीतील .proxybypass फाइलमध्ये प्रॉक्सी बायपास नियम ठेवू शकतो. प्रत्येक ओळ URL शी जुळवली जाणारी ECMAScript रेग्युलर एक्सप्रेशन आहे.

उदाहरणार्थ, एका अंतर्गत फीड होस्टसाठीचा नियम असा दिसू शकतो:

^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)

हे एक्सप्रेशन त्या होस्टसाठी HTTP किंवा HTTPS URL शी जुळते, ऐच्छिक संख्यात्मक पोर्टसह. होस्टनावानंतरची सीमा packages.internal.example.other-domain सारख्या लांब नावाशीही जुळण्यास प्रतिबंध करते.

ही एजंट इन्स्टॉलेशनची फाइल आहे, स्रोत चेकआउटमध्ये हेतूपूर्वक न ठेवलेली फाइल नाही. तिचा सिंटॅक्स स्वल्पविरामाने विभक्त NO_PROXY मूल्यापेक्षाही वेगळा आहे. *.internal.example सारखे शेल वाइल्डकार्ड रेग्युलर-एक्सप्रेशन फील्डमध्ये कॉपी केल्याने तोच अर्थ टिकून राहत नाही.

मग पॅकेज कोण डाउनलोड करतो ते ओळखा

एजंटचे अंगभूत स्रोत आणि आर्टिफॅक्ट ऑपरेशन्स त्याचे प्रॉक्सी कॉन्फिगरेशन वापरतात. कार्ये कार्य लायब्ररीद्वारे उघड केलेली प्रॉक्सी माहिती मिळवू शकतात आणि ती स्वतःच्या HTTP क्लायंटवर लागू करू शकतात.

बाह्य NuGet, dotnet किंवा curl प्रक्रिया बोलावणारे कार्य आणखी एक ग्राहक जोडते. ते कार्य साधनाला प्रॉक्सी आणि बायपास सेटिंग्ज कशा पुरवते याची खात्री करा. योग्य एजंट नियम हे सिद्ध करत नाही की प्रत्येक स्वतंत्र पॅकेज क्लायंटने तो वाचला आहे.

अंतर्गत फीड URL स्कीम आणि पोर्टसह निदान नोंदीत ठेवा. संपर्क केला जाणारा URL यावर नियम तपासा, नंतर त्या विनंतीसाठी जबाबदार कार्य किंवा क्लायंट कॉन्फिगरेशन तपासा.

संबंधित लेख