Azure Pipelines: NuGet Restore-ის პროქსი გარემოს დაყენება

მიაწოდეთ restore პროცესს http_proxy და no_proxy მაშინაც, როცა NuGetAuthenticate-მა უკვე დააყენა feed-ების სერტიფიკატები.

NuGetAuthenticate აყენებს ავთენტიფიკაციას პაკეტების feed-ებთან. წარმატებული ავთენტიფიკაციის ამოცანა არ აყენებს გამავალ პროქსის dotnet-ისთვის, nuget.exe-ისთვის ან MSBuild-ისთვის.

თუ სერტიფიკატების დაყენება წარმატებით დასრულდა და შემდეგ restore-ს სჭირდება HTTP პროქსი, მიაწოდეთ ამ პროცესის გარემო. მაგალითად:

- task: NuGetAuthenticate@1

- script: dotnet restore
  env:
    http_proxy: $(proxyUrl)
    no_proxy: packages.corp.example,localhost,127.0.0.1

proxyUrl არსებული pipeline ცვლადია, რომელიც შეიცავს სასურველ სრულ პროქსი URL-ს. მოარგეთ გამოტოვების სია feed-ების ფაქტობრივ მარშრუტიზაციის პოლიტიკას. საჯარო შუამავლის მეშვეობით დაშვებული საჯარო feed-ებისთვის HTTP პროქსების სია გთავაზობთ კანდიდატებს ანგარიშის გარეშე proxyUrl-ისთვის; შეინარჩუნეთ კერძო feed-ების გამოტოვებები. ეს ფრაგმენტი ვარაუდობს, რომ პროექტის პაკეტების წყაროები უკვე დაყენებულია.

Linux-სა და macOS-ზე დოკუმენტირებული გარემოს სახელები პატარა ასოებითაა. http_proxy სახელის pipeline ცვლადი ავტომატური ექსპორტისას შეიძლება გახდეს დიდი ასოებით. env-ის მკაფიო დაკავშირება ინარჩუნებს გასაღებს, რომელიც ინსტრუმენტს სჭირდება.

თვითჰოსტინგიანი agent-ისთვის სხვა ვარიანტია ამ მნიშვნელობების დაყენება agent-ის პროცესის გარემოში და შეცვლის შემდეგ იმ agent-ის ხელახლა გაშვება. სხვა ტერმინალის გარემო არ აახლებს უკვე მომუშავე სერვისს.

NuGet ასევე მხარს უჭერს პროქსის ჩანაწერებს თავის კონფიგურაციაში. შეინახეთ ისინი პაკეტების წყაროების სერტიფიკატებისგან ცალკე და შეამოწმეთ კონფიგურაციის ფაქტობრივი არეალი, როცა restore სხვა ანგარიშით მუშაობს.

აღდგენილ პაკეტს შეიძლება სჭირდებოდეს feed-ის პირველ URL-ზე მეტი. თუ მოგვიანებით პაკეტის ჩამოტვირთვა ან ავთენტიფიკაციის ჰოსტი ვერ მოხერხდა, პროქსისა და გამოტოვების პოლიტიკის შეფასებისას გამოიყენეთ ის ფაქტობრივი ჰოსტის სახელი.

დაკავშირებული სტატიები