Azure Pipelines: NuGet Restore-এর প্রক্সি এনভায়রনমেন্ট সেট করুন
NuGetAuthenticate ইতিমধ্যে ফিড শংসাপত্র কনফিগার করলেও restore প্রক্রিয়াকে http_proxy ও no_proxy দিন।
NuGetAuthenticate প্যাকেজ ফিডের জন্য প্রমাণীকরণ কনফিগার করে। সফল প্রমাণীকরণ টাস্ক 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.1proxyUrl একটি বিদ্যমান পাইপলাইন ভেরিয়েবল, যাতে অভীষ্ট সম্পূর্ণ প্রক্সি URL আছে। বাইপাস তালিকাটি ফিডের প্রকৃত রাউটিং নীতির সাথে মিলিয়ে নিন। পাবলিক মধ্যস্থতাকারীর মাধ্যমে অনুমোদিত পাবলিক ফিডের জন্য HTTP প্রক্সি তালিকা অ্যাকাউন্টহীন proxyUrl-এর জন্য প্রার্থী দেয়; প্রাইভেট ফিডের বাইপাস যথাস্থানে রাখুন। এই অংশটি ধরে নেয় যে প্রকল্পের প্যাকেজ উৎস ইতিমধ্যে কনফিগার করা হয়েছে।
Linux ও macOS-এ নথিভুক্ত এনভায়রনমেন্ট নামগুলো ছোট হাতের। http_proxy নামের পাইপলাইন ভেরিয়েবল স্বয়ংক্রিয়ভাবে রপ্তানি হলে বড় হাতের হতে পারে। স্পষ্ট env ম্যাপিং টুলটির প্রয়োজনীয় কী সংরক্ষণ করে।
স্ব-হোস্টেড এজেন্টের জন্য আরেকটি উপায় হলো এই মানগুলো এজেন্ট প্রক্রিয়ার এনভায়রনমেন্টে সেট করা এবং পরিবর্তনের পর সেই এজেন্ট পুনরায় চালু করা। অন্য টার্মিনালের এনভায়রনমেন্ট ইতিমধ্যে চলমান সেবা হালনাগাদ করে না।
NuGet তার কনফিগারেশনে প্রক্সি এন্ট্রিও সমর্থন করে। সেগুলো প্যাকেজ-উৎস শংসাপত্র থেকে আলাদা রাখুন, এবং restore অন্য অ্যাকাউন্টের অধীনে চললে কার্যকর কনফিগারেশন পরিধি যাচাই করুন।
পুনরুদ্ধার করা প্যাকেজ ফিডের প্রথম URL-এর চেয়ে বেশি কিছু প্রয়োজন হতে পারে। পরে কোনো প্যাকেজ ডাউনলোড বা প্রমাণীকরণ হোস্ট ব্যর্থ হলে, প্রক্সি ও বাইপাস নীতি মূল্যায়নের সময় সেই প্রকৃত হোস্টনাম ব্যবহার করুন।