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