-
Task
-
Resolution: Fixed
-
Major
-
None
-
-
4265.v78b_d4a_1c864a_
When a Jetty 12 Jenkins test harness is used (i.e., one built from the prototype branch of jenkins-test-harness), tests based on these harnesses fail:
- src/test/java/org/jvnet/hudson/test/JenkinsRuleNonLocalhost.java
- src/test/java/org/jvnet/hudson/test/RestartableJenkinsNonLocalhostRule.java
Ideally a change could be found that can be delivered against the current release of Jetty 10 while also being forward compatible with Jetty 12. If not, then the PR will have to remain in draft until we release JTH with Jetty 12 support. Either way, we should prepare the PR in advance.
- is blocking
-
JENKINS-73282 Run PCT with a Jetty 12 EE 8 test harness when core is Jetty 12 EE 8
-
- Closed
-
- links to
JenkinsRuleNonLocalhost was not a great idea to begin with. https://github.com/jenkinsci/kubernetes-plugin/pull/1567#pullrequestreview-2090682601 has some related discussion, but briefly: the problem is that K8s agents are inbound (JNLPLauncher, whether TCP or WebSocket) and when the controller runs outside the cluster they would not be able to access it easily because they are not both on localhost, and the host IP is not readily accessible. CI tests do not have quite the same issue because they run mvn test inside the cluster so there is a well-defined host name, but it is still not on loopback. I think this does not matter for the TCP port, but the current hack is to expose the Jenkins HTTP port to all network interfaces, which is not supported in JTH pending https://github.com/jenkinsci/jenkins-test-harness/pull/289#issuecomment-809560892 (since it is so easy to expose yourself to a serious vulnerability unless you take care to ensure that every single test enables security with a strong random password). And so the plugin’s fork of JenkinsRule is awkward to maintain.
It would be safer and more robust to use ktunnel or some similar system to set up a reverse proxy for both ports that allows agent pods running inside the cluster to contact the controller, without exposing the controller’s HTTP port to outside traffic. Ideally this would also be available for hpi:run but at worst you can just add a Thread.sleep to some test, wait for it to pause, and then experiment interactively.