സ്വയം ഹോസ്റ്റ് ചെയ്യുന്ന 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-നെതിരെ നിയമം പരീക്ഷിച്ച്, പിന്നീട് ആ അഭ്യർത്ഥനയുടെ ഉത്തരവാദിയായ ടാസ്ക് അല്ലെങ്കിൽ ക്ലയന്റ് കോൺഫിഗറേഷൻ പരിശോധിക്കുക.

അനുബന്ധ ലേഖനങ്ങൾ