NuGetAuthenticate এ পেকেজ ফিডৰ বাবে প্ৰমাণীকৰণ ছেট কৰে। সফল প্ৰমাণীকৰণ টাস্কে dotnet, nuget.exe বা MSBuild ৰ বাবে আউটবাউণ্ড প্ৰক্সি ছেট নকৰে।

যদি credential ছেটআপ সফল হয় আৰু পৰৱৰ্তী restore ৰ HTTP প্ৰক্সিৰ প্ৰয়োজন হয়, তেন্তে সেই প্ৰক্ৰিয়াৰ পৰিৱেশ যোগান ধৰক। উদাহৰণস্বৰূপে:

- task: NuGetAuthenticate@1

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

proxyUrl এটা বিদ্যমান পাইপলাইন চলক য’ত উদ্দেশ্য কৰা সম্পূৰ্ণ প্ৰক্সি URL আছে। বাইপাছ তালিকাখন প্ৰকৃত ফিড ৰাউটিং নীতিত মিলাই লওক। ৰাজহুৱা মধ্যস্থতাকাৰীৰ যোগেৰে অনুমোদিত ৰাজহুৱা ফিডৰ বাবে HTTP প্ৰক্সি তালিকাএ একাউণ্ট নোহোৱা proxyUrl ৰ বাবে প্ৰাৰ্থী যোগান ধৰে; ব্যক্তিগত ফিডৰ বাইপাছবোৰ ঠাইতে ৰাখক। এই খণ্ডই ধৰি লয় যে প্ৰকল্পৰ পেকেজ উৎসসমূহ ইতিমধ্যে ছেট কৰা হৈছে।

Linux আৰু macOS ত নথিভুক্ত পৰিৱেশৰ নামবোৰ সৰু আখৰত থাকে। http_proxy নামৰ পাইপলাইন চলক এটা স্বয়ংক্ৰিয়ভাৱে ৰপ্তানি হ’লে ডাঙৰ আখৰ হ’ব পাৰে। এটা স্পষ্ট env মেপিঙে সঁজুলিয়ে প্ৰয়োজনীয় key টো ৰক্ষা কৰে।

স্ব-হোষ্ট কৰা agent ৰ বাবে আন এটা বিকল্প হ’ল এই মানবোৰ agent প্ৰক্ৰিয়াৰ পৰিৱেশত ছেট কৰি সিহত সলনি কৰাৰ পিছত সেই agent পুনৰ আৰম্ভ কৰা। অন্য এটা টাৰ্মিনেলৰ পৰিৱেশে ইতিমধ্যে চলি থকা সেৱা আপডেট নকৰে।

NuGet এ নিজৰ configuration ত প্ৰক্সি এন্ট্ৰিও সমৰ্থন কৰে। সেইবোৰ পেকেজ-উৎস credential ৰ পৰা পৃথক ৰাখক, আৰু অন্য একাউণ্টৰ অধীনত restore চলোৱাৰ সময়ত প্ৰভাৱী configuration পৰিসৰ পৰীক্ষা কৰক।

এটা restore কৰা পেকেজে ফিডৰ প্ৰথম URL তকৈ অধিকৰ প্ৰয়োজন হ’ব পাৰে। যদি পিছৰ পেকেজ ডাউনলোড বা প্ৰমাণীকৰণ হোষ্ট বিফল হয়, প্ৰক্সি আৰু বাইপাছ নীতি মূল্যায়ন কৰাৰ সময়ত সেই প্ৰকৃত হোষ্টনাম ব্যৱহাৰ কৰক।

সম্পৰ্কিত প্ৰবন্ধ