GitHub ਵੈਬਹੁੱਕ ਪ੍ਰਾਈਵੇਟ Jenkins ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ: ਰਾਹ ਠੀਕ ਕਰੋ

ਤੁਸੀਂ VPN ਰਾਹੀਂ Jenkins ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ GitHub ਨੂੰ ਅਸਫਲ ਵੈਬਹੁੱਕ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਦੇਖ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਇਹ ਦੋ ਵੱਖਰੇ ਮਾਲਕਾਂ ਵਾਲੇ ਦੋ ਵੱਖਰੇ ਕਨੈਕਸ਼ਨ ਹਨ। ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਸੁਰੰਗ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਨੇ ਗੱਲਬਾਤ ਕੀਤੀ; GitHub ਦੀ ਡਿਲੀਵਰੀ ਸੇਵਾ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਨੈੱਟਵਰਕ ਵਿੱਚ ਇਸਦਾ ਕੋਈ ਰਾਹ ਨਹੀਂ ਹੈ। ਰੈਪੋਜ਼ਿਟਰੀ ਤੱਕ ਪਹੁੰਚ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦੀ, ਭਾਵੇਂ Jenkins ਆਪ ਹੀ ਉਸੇ ਰੈਪੋਜ਼ਿਟਰੀ ਤੋਂ ਬਿਨਾਂ ਮੁਸ਼ਕਲ ਦੇ ਲੈ ਸਕਦਾ ਹੈ। ਕੋਈ ਇਨਗ੍ਰੈਸ, ਰਿਲੇ ਜਾਂ ਪੋਲਿੰਗ ਚੁਣੋ, ਫਿਰ ਉਹ ਰਾਹ ਜਾਂਚੋ ਜੋ ਘਟਨਾ ਅਸਲ ਵਿੱਚ ਲੈਂਦੀ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਸਾਬਤ ਕਰਦਾ ਹੈ

VPN ਕਨੈਕਸ਼ਨ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਇਹ ਲੈਪਟਾਪ ਅੰਦਰੂਨੀ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਵੈਬਹੁੱਕ ਡਿਲੀਵਰੀ ਦੂਜਾ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: ਕੀ ਬਾਹਰੀ ਸੇਵਾ ਉਸ ਹੋਸਟ ਨਾਲ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ। Jenkins ਦਾ ਰੈਪੋਜ਼ਿਟਰੀ ਲੈਣਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਹੈ ਅਤੇ ਅੰਦਰ ਆਉਣ ਵਾਲੀ ਪਹੁੰਚ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਆਪਣੇ ਚਿੱਤਰ ਵਿੱਚ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੱਖਰੀਆਂ ਲਾਈਨਾਂ ਉੱਤੇ ਰੱਖੋ, ਇਹ ਵੀ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਹਰ ਇੱਕ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਡਿਲੀਵਰੀ ਰਿਕਾਰਡ ਪੜ੍ਹੋ। ਟਾਈਮਆਊਟ, ਕਨੈਕਸ਼ਨ ਰੀਸੈਟ ਅਤੇ ਮਨਜ਼ੂਰ ਕੀਤੀ ਬੇਨਤੀ ਜੋ ਕਿਸੇ ਕੰਮ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਸੀ, ਇਹਨਾਂ ਦੇ ਤਿੰਨ ਵੱਖਰੇ ਮਾਲਕ ਹਨ: ਨੈੱਟਵਰਕ, ਪ੍ਰੌਕਸੀ ਅਤੇ ਟ੍ਰਿਗਰ ਸੰਰਚਨਾ।

ਵਿਕਲਪ A: ਸੰਖੇਪ ਐਂਡਪੁਆਇੰਟ ਖੋਲ੍ਹੋ

ਜੇ ਸੰਸਥਾ ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਇਨਗ੍ਰੈਸ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ ਡੈਸ਼ਬੋਰਡ ਦੀ ਥਾਂ ਵੈਬਹੁੱਕ ਦਾ ਰਾਹ ਖੋਲ੍ਹੋ। ਆਮ ਤੌਰ ਉੱਤੇ ਇਸਦਾ ਮਤਲਬ ਹੁੱਕ URL ਉੱਤੇ POST ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ Jenkins ਤੱਕ ਭੇਜਣ ਵਾਲਾ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਨਿਯਮ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰਸ਼ਾਸਨਿਕ ਇੰਟਰਫੇਸ ਬਾਹਰੋਂ ਅਪਹੁੰਚ ਰਹਿੰਦਾ ਹੈ।

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

ਉਹ ਟੈਸਟ VPN ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਤੋਂ ਚਲਾਓ, ਕਿਉਂਕਿ ਸੁਰੰਗ ਦੇ ਅੰਦਰੋਂ ਸਫਲਤਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਸਾਂਝੇ ਭੇਤ ਤੋਂ ਬਿਨਾਂ ਬੇਨਤੀਆਂ ਰੱਦ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਜੋ GitHub ਦਸਤਖਤ ਹੈਡਰ ਵਜੋਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਇੱਕ ਰਾਹ ਅਤੇ ਢੰਗ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ। ਜਨਤਕ Jenkins ਕੰਸੋਲ ਵੈਬਹੁੱਕ ਦਾ ਹੱਲ ਨਹੀਂ ਹੈ; ਇਹ ਅਗਲੇ ਸਕੈਨਰ ਦੀ ਉਡੀਕ ਕਰਦੀ ਘਟਨਾ ਹੈ। ਨਿਯਮ ਨੂੰ ਇੰਨਾ ਸਖ਼ਤ ਰੱਖੋ ਕਿ ਬਾਕੀ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਪਹਿਲੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਬਣਾਈ ਰੱਖੇ।

ਵਿਕਲਪ B: ਰਿਲੇ ਨਾਲ ਦਿਸ਼ਾ ਪਲਟੋ

ਜਿੱਥੇ ਅੰਦਰ ਆਉਣ ਵਾਲਾ ਖੁਲਾਸਾ ਮਨਜ਼ੂਰ ਨਹੀਂ ਹੋਵੇਗਾ, ਉੱਥੇ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਇੱਕ ਛੋਟਾ ਕਲਾਇੰਟ ਰਿਲੇ ਵੱਲ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਰੱਖ ਸਕਦਾ ਹੈ ਅਤੇ ਭੇਜੀਆਂ ਘਟਨਾਵਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਰ ਰਿਲੇ ਡਿਲੀਵਰੀ ਰਾਹ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਦੀ ਉਪਲਬਧਤਾ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਬਿਲਡ ਕੰਮ ਜਿੰਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ssh -N -R 9000:localhost:8080 relay.example.net

ਫਾਇਰਵਾਲਾਂ ਪਿੱਛੇ ਵੈਬਹੁੱਕਾਂ ਬਾਰੇ Jenkins ਦੀ ਸੇਧ ਇਸ ਰੂਪ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਆਪਣਾ ਫਾਰਵਰਡਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ। ਰਿਲੇ ਉੱਤੇ TLS ਖਤਮ ਕਰੋ, ਘਟਨਾ ਦੇ ਕੰਮ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਦਸਤਖਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਕੜੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ, ਕਿਉਂਕਿ ਡਿੱਗੀ ਸੁਰੰਗ ਬਿਲਕੁਲ ਉਸ ਘਟਨਾ ਵਰਗੀ ਦਿਖਦੀ ਹੈ ਜੋ ਕਦੇ ਭੇਜੀ ਨਹੀਂ ਗਈ। ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਲੇ ਬੇਨਤੀ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਬਾਈਟ ਪ੍ਰਤੀ ਬਾਈਟ ਸੰਭਾਲਦਾ ਹੈ, ਕਿਉਂਕਿ ਰਾਹ ਵਿੱਚ ਪਾਰਸ ਅਤੇ ਦੁਬਾਰਾ ਐਨਕੋਡ ਕੀਤੇ JSON ਉੱਤੇ ਦਸਤਖਤ ਜਾਂਚ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ।

ਵਿਕਲਪ C: ਇਸਦੀ ਥਾਂ ਰੈਪੋਜ਼ਿਟਰੀ ਪੋਲ ਕਰੋ

ਪੋਲਿੰਗ ਦੇਰੀ ਨੂੰ ਸਾਦਗੀ ਨਾਲ ਬਦਲਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਅੰਦਰ ਆਉਣ ਵਾਲੇ ਰਾਹ ਦੀ ਜ਼ਰੂਰਤ ਹੀ ਨਹੀਂ। Jenkins ਸ਼ਡਿਊਲ ਅਨੁਸਾਰ ਪੋਲ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਛੋਟਾ ਕੰਮ API ਨੂੰ ਪੁੱਛ ਕੇ ਅਣਜਾਣ ਸੰਸ਼ੋਧਨ ਦੇਖ ਕੇ ਬਿਲਡ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

ਹਰ ਪੋਲ API ਕਾਲਾਂ ਖਰਚਦੀ ਹੈ ਅਤੇ push ਤੇ ਬਿਲਡ ਵਿਚਕਾਰ ਦੇਰੀ ਜੋੜਦੀ ਹੈ, ਜੋ ਰੁੱਝੀਆਂ ਰੈਪੋਜ਼ਿਟਰੀਆਂ ਅਤੇ ਸਾਂਝੀਆਂ ਦਰ ਸੀਮਾਵਾਂ ਉੱਤੇ ਦਿਖਦੀ ਹੈ। ਇਸਨੂੰ ਉੱਥੇ ਸੰਗ੍ਰਹਿਤ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵੀ ਚਾਹੀਦੇ ਹਨ ਜਿੱਥੇ ਪੋਲਰ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਟੋਕਨ ਨੂੰ ਰੈਪੋਜ਼ਿਟਰੀ ਤੱਕ ਸਿਰਫ਼ ਪੜ੍ਹਨ ਦੀ ਪਹੁੰਚ ਤੱਕ ਸੀਮਿਤ ਕਰੋ ਅਤੇ ਕਿਸੇ ਹੋਰ ਭੇਤ ਵਾਂਗ ਇਸਨੂੰ ਬਦਲਦੇ ਰਹੋ। ਇਹ ਤਦ ਚੁਣੋ ਜਦੋਂ ਘਟਨਾਵਾਂ ਦੀ ਮਾਤਰਾ ਘੱਟ ਹੋਵੇ ਜਾਂ ਜਦੋਂ ਕੋਈ ਇਨਗ੍ਰੈਸ ਕਦੇ ਮਨਜ਼ੂਰ ਨਾ ਹੋਵੇ, ਅਤੇ ਕੰਮ ਦੇ ਵਰਣਨ ਵਿੱਚ ਇਹ ਲਿਖੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਨੂੰ ਹੈਰਾਨੀ ਨਾ ਹੋਵੇ ਕਿ ਬਿਲਡ ਕਿਉਂ ਪਿੱਛੇ ਰਹਿ ਰਹੇ ਹਨ।

ਪੰਨਾ ਲੋਡ ਨਹੀਂ, ਅਸਲ ਡਿਲੀਵਰੀ ਸਵੀਕਾਰ ਕਰੋ

ਤੁਸੀਂ ਕੋਈ ਵੀ ਵਿਕਲਪ ਚੁਣਿਆ ਹੋਵੇ, ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਸਰੋਤ ਪਲੇਟਫਾਰਮ ਵੱਲੋਂ ਭੇਜੀ ਘਟਨਾ ਹੈ, ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਲੈਪਟਾਪ ਤੋਂ ਖੋਲ੍ਹੀ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਨਹੀਂ। ਸਕ੍ਰੈਚ ਸ਼ਾਖਾ ਵਿੱਚ ਖਾਲੀ commit push ਕਰੋ ਅਤੇ ਡਿਲੀਵਰੀ ਜਵਾਬ ਕੋਡ, ਰਿਲੇ ਲੌਗ ਜਾਂ ਪੋਲਿੰਗ ਕੰਮ ਦਾ ਆਉਟਪੁੱਟ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੜ੍ਹੋ। ਐਂਡਪੁਆਇੰਟ ਤੋਂ 200 ਅਤੇ ਬਿਲਡ ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ ਟ੍ਰਿਗਰ ਫਿਲਟਰ ਗਲਤ ਹੈ; ਟਾਈਮਆਊਟ ਦਾ ਮਤਲਬ ਰਾਹ ਅਜੇ ਵੀ ਬੰਦ ਹੈ। ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ ਇਹ ਦਰਜ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਅੱਗੇ ਡੀਬੱਗ ਕਰਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਟੈਸਟ ਦੁਹਰਾਏਗਾ ਅਤੇ ਉਸੇ ਬੰਦ ਗਲੀ ਵਿੱਚ ਪਹੁੰਚੇਗਾ।

ਭੁਗਤਾਨ ਕਾਲਬੈਕ ਅਤੇ ਹੋਰ ਬਾਹਰੀ ਸੂਚਨਾਵਾਂ ਉੱਤੇ ਵੀ ਇਹੀ ਤਰਕ ਲਾਗੂ ਕਰੋ: ਹਰ ਵਿਅਕਤੀ ਕੋਲ ਪਹਿਲਾਂ ਹੀ VPN ਸੈਸ਼ਨ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਹਰ ਇੱਕ ਨੂੰ ਪ੍ਰਾਈਵੇਟ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਆਪਣਾ ਰਾਹ ਚਾਹੀਦਾ ਹੈ। ਡਿਲੀਵਰੀ ਰਾਹ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹੈ, ਨੈੱਟਵਰਕਿੰਗ ਦੀ ਹਾਸ਼ੀਏ ਦੀ ਟਿੱਪਣੀ ਦਾ ਨਹੀਂ।