Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Seen as far back as v3.7 on Jenkins 2.43, and as recent as v3.15 on Jenkins 2.107
Description
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
Thanks for the suggestion oleg_nenashev
I went ahead and added the label. The sooner we can get the change the better for us (and we would need it in an LTS release). Based on my work on the PR, where the code path in particular had not changed in a while, I think
the change should be an easy backport. But of course I'll defer to jeffret for the final call there.