'n Self-gehoste Azure Pipelines-agent kan proxy-omseilreels in 'n .proxybypass-lêer in sy wortelgids hou. Elke reël is 'n ECMAScript-reguliere uitdrukking wat teen 'n URL gepas word.

Byvoorbeeld, 'n reël vir een interne voerhost kan so lyk:

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

Die uitdrukking pas HTTP- of HTTPS-URL's vir daardie host, met 'n opsionele numeriese poort. Die grens ná die hostnaam verhoed dat 'n langer naam soos packages.internal.example.other-domain ook gepas word.

Dit is die lêer van die agent-installasie, nie 'n lêer wat willekeurig in die bronkode-kopie geplaas is nie. Die sintaks verskil ook van 'n kommageskeide NO_PROXY-waarde. Om 'n skelpatroon soos *.internal.example na 'n veld vir reguliere uitdrukkings te kopieer, behou nie dieselfde betekenis nie.

Identifiseer dan wie die pakket aflaai

Die agent se ingeboude bron- en artefakbewerkings gebruik sy proxy-konfigurasie. Take kan blootgestelde proxy-inligting deur die taakbiblioteek kry en op hul eie HTTP-kliënte toepas.

'n Taak wat 'n eksterne NuGet-, dotnet- of curl-proses aanroep, voeg nog 'n verbruiker by. Bevestig hoe daardie taak proxy- en omseilinstellings aan die gereedskap gee. 'n Korrekte agent-reël bewys nie dat elke onafhanklike pakketkliënt dit gelees het nie.

Hou die interne voer-URL in die diagnostiese rekord, insluitend die skema en die poort. Toets die reël teen die URL wat gekontak word, en ondersoek dan die taak- of kliëntkonfigurasie wat vir daardie versoek verantwoordelik is.

Verwante artikels