Një agjent Azure Pipelines i vetëstrehuar mund të mbajë rregulla anashkalimi të proxy-t në një skedar .proxybypass në drejtorinë e tij rrënjësore. Çdo rresht është një shprehje e rregullt ECMAScript që përputhet me një URL.

Për shembull, një rregull për një host të brendshëm të furnizimit mund të duket kështu:

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

Shprehja përputhet me URL HTTP ose HTTPS për atë host, me një port numerik opsional. Kufiri pas emrit të hostit shmang përputhjen edhe me një emër më të gjatë si packages.internal.example.other-domain.

Ky është skedari i instalimit të agjentit, jo një skedar i vendosur në mënyrë arbitrare në kopjen e punës të kodit burimor. Sintaksa e tij ndryshon gjithashtu nga një vlerë NO_PROXY e ndarë me presje. Kopjimi i një karakteri të egër shell si *.internal.example në një fushë shprehjeje të rregullt nuk ruan të njëjtin kuptim.

Më pas identifikoni kush e shkarkon paketën

Operacionet e integruara të burimit dhe artefaktit të agjentit përdorin konfigurimin e tij të proxy-t. Detyrat mund të marrin informacionin e ekspozuar të proxy-t përmes bibliotekës së detyrave dhe ta zbatojnë atë në klientët e tyre HTTP.

Një detyrë që thërret një proces të jashtëm NuGet, dotnet ose curl sjell një konsumator tjetër. Konfirmoni se si ajo detyrë i siguron mjetit cilësimet e proxy-t dhe anashkalimit. Një rregull i saktë i agjentit nuk provon që çdo klient i pavarur i paketave e ka lexuar atë.

Mbajeni URL-në e furnizimit të brendshëm në regjistrin diagnostik, duke përfshirë skemën dhe portën. Testoni rregullin kundër URL-së me të cilën kontaktohet, më pas shqyrtoni konfigurimin e detyrës ose klientit përgjegjës për atë kërkesë.

Artikuj të ngjashëm