-
Bug
-
Resolution: Fixed
-
Major
-
Seen as far back as v3.7 on Jenkins 2.43, and as recent as v3.15 on Jenkins 2.107
The regular expression algorithm in org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.inNoProxyEnvVar(String)(String) does not match when a single element of a fully qualified hostname and domain is part of the no_proxy setting.
For example, taking a host name of "jenkins.bnd-cd.svc", we tried adding ".svc", "svc", and "*.svc", "*svc", and none of them matched.
We had to specify "bnd-cd.svc" in the no_proxy evn var.
By comparison, in th same env, we were able to run curl with a no_proxy evn var containing ".svc" and it properly matched "jenkins.bnd-cd.svc"
When running in kubernetes/openshift, having to specify "bnd-cd.svc" is problematic as "bnd-cd" corresponds to the project/namespace, and "svc" was the default suffix applied to all service hostnames. We wanted to have the http_proxy/no_proxy settings be applicable across jenkins running in any project/namespace.
In addition to proving this when running an end to end Jenkins master/agent scenario using the standard jar, we also
a) took the logic from org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.inNoProxyEnvVar(String) and put it in a simple main program where we set host and no_proxy accordingly
b) create debug versions of remoting.jar with additional LOGGER calls to trace the behavior
Code changed in jenkins
User: gabemontero
Path:
src/main/java/hudson/remoting/Util.java
src/main/java/org/jenkinsci/remoting/engine/JnlpAgentEndpointResolver.java
src/test/java/hudson/remoting/UtilTest.java
http://jenkins-ci.org/commit/remoting/0272a4302e5eb3d619530fdb3e1ab4f45663a9b3
Log:
JENKINS-51223catch more domain suffix based no_proxy matches (add curl-like algorithm to existing regexp)remove some of the duplicate JnlpAgentEndpointResolver/Util code