ଏକ ସ୍ୱୟଂ-ହୋଷ୍ଟ କରାଯାଇଥିବା 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 ଉପରେ ନିୟମ ପରୀକ୍ଷା କରନ୍ତୁ, ତାପରେ ସେହି ଅନୁରୋଧ ପାଇଁ ଦାୟୀ କାର୍ଯ୍ୟ କିମ୍ବା କ୍ଲାଏଣ୍ଟ କନଫିଗରେସନ୍ ଯାଞ୍ଚ କରନ୍ତୁ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ