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 સામે નિયમનું પરીક્ષણ કરો, પછી તે વિનંતી માટે જવાબદાર ટાસ્ક અથવા ક્લાયન્ટ રૂપરેખા તપાસો.