Ein sjølvhosta Azure Pipelines-agent kan ha proxyomgåingsreglar i ei .proxybypass-fil i rotmappa si. Kvar linje er eit ECMAScript-regulært uttrykk som blir samanlikna med ein URL.

Til dømes kan ein regel for ein intern feed-vert sjå slik ut:

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

Uttrykket passar med HTTP- eller HTTPS-URL-ar for den verten, med ein valfri numerisk port. Grensa etter vertsnamnet hindrar òg samsvar med eit lengre namn som packages.internal.example.other-domain.

Dette er fila til agentinstallasjonen, ikkje ei fil som vilkårleg er plassert i kjeldekode-utsjekkinga. Syntaksen skil seg òg frå ein kommaseparert NO_PROXY-verdi. Kopiering av eit skaljokerteikn som *.internal.example til eit felt for regulære uttrykk bevarar ikkje same tyding.

Identifiser deretter kven som lastar ned pakken

Dei innebygde kjelde- og artefaktoperasjonane til agenten brukar proxykonfigurasjonen sin. Oppgåver kan hente eksponert proxyinformasjon gjennom oppgåvebiblioteket og bruke han på sine eigne HTTP-klientar.

Ei oppgåve som kallar ein ekstern NuGet-, dotnet- eller curl-prosess introduserer endå ein forbrukar. Stadfest korleis oppgåva gir verktøyet proxy- og omgåingsinnstillingar. Ein korrekt agentregel bevisar ikkje at kvar uavhengig pakkeklient har lese han.

Hald URL-en til den interne feeden i den diagnostiske posten, inkludert skjema og port. Test regelen mot URL-en som blir kontakta, og undersøk deretter oppgåve- eller klientkonfigurasjonen som er ansvarleg for førespurnaden.

Relaterte artiklar