Azure Pipelines ਏਜੰਟ ਦੇ .proxybypass URL ਪੈਟਰਨ

ਇੱਕ ਸਵੈ-ਹੋਸਟ ਕੀਤਾ 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 ਉੱਤੇ ਨਿਯਮ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਉਸ ਬੇਨਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਟਾਸਕ ਜਾਂ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਵੇਖੋ।