Azure Pipelines აგენტის .proxybypass URL შაბლონები
გამოიყენეთ ECMAScript რეგულარული გამოსახულებები თვით-ჰოსტინგური Azure Pipelines აგენტის ძირეულ საქაღალდეში და შეამოწმეთ დავალების საკუთარი პროქსის ინტეგრაცია.
თვით-ჰოსტინგურ Azure Pipelines აგენტს შეუძლია პროქსის გვერდის ავლის წესები შეინახოს თავის ძირეულ საქაღალდეში არსებულ .proxybypass ფაილში. ყოველი ხაზი ECMAScript რეგულარული გამოსახულებაა, რომელიც URL-ს ედარება.
მაგალითად, ერთი შიდა feed-ჰოსტის წესი ასე შეიძლება გამოიყურებოდეს:
^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)
გამოსახულება ემთხვევა ამ ჰოსტის HTTP ან HTTPS URL-ებს, სურვილისამებრ რიცხვითი პორტით. ჰოსტის სახელის შემდგომი საზღვარი ხელს უშლის უფრო გრძელი სახელის, მაგალითად packages.internal.example.other-domain-ის, დამთხვევას.
ეს აგენტის ინსტალაციის ფაილია და არა ფაილი, რომელიც თვითნებურადაა მოთავსებული წყარო კოდის სამუშაო ასლში. მისი სინტაქსი ასევე განსხვავდება მძიმეებით გამოყოფილი NO_PROXY მნიშვნელობისგან. shell-ის ველური სიმბოლოს, მაგალითად *.internal.example-ის, რეგულარული გამოსახულების ველში კოპირება იმავე მნიშვნელობას არ ინარჩუნებს.
შემდეგ დაადგინეთ, ვინ ტვირთავს პაკეტს
აგენტის ჩაშენებული წყაროსა და არტეფაქტის ოპერაციები იყენებენ მის პროქსის კონფიგურაციას. დავალებებს შეუძლიათ დავალებების ბიბლიოთეკის მეშვეობით მიიღონ გამჟღავნებული პროქსის ინფორმაცია და გამოიყენონ საკუთარ HTTP კლიენტებზე.
დავალება, რომელიც იძახებს გარე NuGet, dotnet ან curl პროცესს, კიდევ ერთ მომხმარებელს ნერგავს. დაადასტურეთ, როგორ აწვდის ეს დავალება ხელსაწყოს პროქსისა და გვერდის ავლის პარამეტრებს. სწორი აგენტის წესი არ ამტკიცებს, რომ ყველა დამოუკიდებელმა პაკეტის კლიენტმა წაიკითხა ის.
შეინახეთ შიდა feed-ის URL დიაგნოსტიკურ ჩანაწერში, სქემისა და პორტის ჩათვლით. გამოსცადეთ წესი იმ URL-ზე, რომელთანაც კავშირი მყარდება, შემდეგ შეამოწმეთ ამ მოთხოვნაზე პასუხისმგებელი დავალების ან კლიენტის კონფიგურაცია.