Azure Pipelines এজেন্টের .proxybypass URL প্যাটার্ন
স্ব-হোস্ট করা Azure Pipelines এজেন্টের রুট ডিরেক্টরিতে ECMAScript রেগুলার এক্সপ্রেশন ব্যবহার করুন এবং টাস্কের নিজস্ব প্রক্সি ইন্টিগ্রেশন যাচাই করুন।
একটি স্ব-হোস্ট করা Azure Pipelines এজেন্ট তার রুট ডিরেক্টরির একটি .proxybypass ফাইলে প্রক্সি বাইপাস নিয়ম রাখতে পারে। প্রতিটি লাইন একটি ECMAScript রেগুলার এক্সপ্রেশন, যা একটি URL-এর সঙ্গে মেলানো হয়।
উদাহরণস্বরূপ, একটি অভ্যন্তরীণ ফিড হোস্টের নিয়ম এমন দেখাতে পারে:
^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)
এক্সপ্রেশনটি ওই হোস্টের HTTP বা HTTPS URL মেলায়, ঐচ্ছিক সংখ্যাসূচক পোর্টসহ। হোস্টনামের পরে সীমাটি packages.internal.example.other-domain-এর মতো দীর্ঘ নামও মেলানো প্রতিরোধ করে।
এটি এজেন্ট ইনস্টলেশনের ফাইল, সোর্স চেকআউটে যথেচ্ছভাবে রাখা ফাইল নয়। এর সিনট্যাক্স কমা-বিভক্ত NO_PROXY মান থেকেও আলাদা। *.internal.example-এর মতো একটি শেল ওয়াইল্ডকার্ড রেগুলার-এক্সপ্রেশন ফিল্ডে কপি করলে একই অর্থ সংরক্ষিত হয় না।
তারপর চিহ্নিত করুন কে প্যাকেজ ডাউনলোড করে
এজেন্টের অন্তর্নির্মিত সোর্স ও আর্টিফ্যাক্ট অপারেশন এর প্রক্সি কনফিগারেশন ব্যবহার করে। টাস্কগুলি টাস্ক লাইব্রেরির মাধ্যমে প্রকাশিত প্রক্সি তথ্য পেতে এবং তা নিজেদের HTTP ক্লায়েন্টে প্রয়োগ করতে পারে।
বহিঃস্থ NuGet, dotnet বা curl প্রক্রিয়া আহ্বানকারী টাস্ক আরেকটি ভোক্তা যোগ করে। ওই টাস্ক কীভাবে টুলটিকে প্রক্সি ও বাইপাস সেটিংস সরবরাহ করে তা নিশ্চিত করুন। সঠিক এজেন্ট নিয়ম প্রমাণ করে না যে প্রতিটি স্বতন্ত্র প্যাকেজ ক্লায়েন্ট তা পড়েছে।
অভ্যন্তরীণ ফিড URL ডায়াগনস্টিক রেকর্ডে রাখুন, তার স্কিম ও পোর্টসহ। যে URL-এ যোগাযোগ করা হচ্ছে তার বিরুদ্ধে নিয়মটি পরীক্ষা করুন, তারপর ওই অনুরোধের জন্য দায়ী টাস্ক বা ক্লায়েন্ট কনফিগারেশন পরীক্ষা করুন।