Shell.DescriptorImpl.getShellOrDefault is not reliable in the presence of LauncherDecorator #95
Conversation
…e of LauncherDecorator.
|
Hmm, some sort of CI problem… |
|
|
||
| public static final String SLIM_JAVA_LOCATION = "/usr/local/openjdk-8/bin/java"; |
There was a problem hiding this comment.
for me it's /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/ :)
TBH I haven't been trough all the code to be able to really understand this so maybe I'm wrong with my comment but I was a bit doh :)
There was a problem hiding this comment.
This is about location inside openjdk:8-jre-slim, which changed recently with docker-library/openjdk#322 and was not in any of the expected locations apparently.
(docker-fixtures rebuilds images from Dockerfile on demand, and our base images are not immutable tags, so we are in the unfortunate position that CI builds sometimes fail for reasons unrelated to the patch at hand, as here.)
There was a problem hiding this comment.
@jglick thanks for the explanation
|
Just because the container running the Jenkins agent has
/bin/shdoes not mean the container running the actual process will. For that matter, the remote callable does not even check—it just blindly returns/bin/shon non-Windows platforms. Useless.May conflict with #92, though that retains the shell launcher as a fallback.
See jenkinsci/kubernetes-plugin#490 for integration test.