Mga pattern ng URL sa .proxybypass ng Azure Pipelines agent

Ang self-hosted na Azure Pipelines agent ay maaaring magtabi ng proxy bypass rules sa isang .proxybypass file sa root directory nito. Bawat linya ay ECMAScript regular expression na itinatapat sa isang URL.

Halimbawa, ang rule para sa isang internal feed host ay maaaring ganito:

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

Itinatapat ng expression ang HTTP o HTTPS na URL ng host na iyon, na may opsyonal na numeric na port. Pinipigilan ng hangganan pagkatapos ng hostname ang pagtapat din sa mas mahabang pangalan tulad ng packages.internal.example.other-domain.

Ito ang file ng installation ng agent, hindi isang file na basta inilagay sa source checkout. Iba rin ang syntax nito sa NO_PROXY value na hinahati ng kuwit. Ang pagkopya ng shell wildcard tulad ng *.internal.example sa field ng regular expression ay hindi nagpapanatili ng parehong kahulugan.

Pagkatapos, tukuyin kung sino ang nagda-download ng package

Ginagamit ng built-in na source at artifact operations ng agent ang proxy configuration nito. Makakakuha ang mga task ng nakalantad na proxy information sa pamamagitan ng task library at mailalapat ito sa sarili nilang HTTP client.

Ang task na tumatawag ng external na NuGet, dotnet o curl process ay nagdadagdag ng isa pang consumer. Tiyakin kung paano ibinibigay ng task na iyon sa tool ang proxy at bypass settings. Hindi pinapatunayan ng tamang agent rule na nabasa ito ng bawat independenteng package client.

Itago ang URL ng internal feed sa diagnostic record, kasama ang scheme at port. Subukan ang rule laban sa URL na kinokontak, pagkatapos suriin ang task o client configuration na responsable sa kahilingang iyon.