yet-another-docker-plugin

yet-another-docker-plugin copied to clipboard

Right now, init.sh only supports java and depends on the $PATH to sort out which version. In the SSH launcher, the java binary path can be specified.

It would be nice to be able to specify the Java path without using environment variables or tools.

Slave template has node properties, probably you can append PATH via it += or somehow. Afair jenkins had append vars magic.

Except: https://github.com/KostyaSha/yet-another-docker-plugin/blob/80c991f821c3a68354e8c744c9fd876810f88e28/yet-another-docker-plugin/src/main/resources/com/github/kostyasha/yad/launcher/DockerComputerJNLPLauncher/init.sh#L103

Running su - ... will create a clean environment discarding any customization Jenkins would make from the environment or path side.

but some vars will be added during build. Ok that not right level that i thought about. Some vars will be added only after jenkins slave.jar run and you mean before executing slave.jar..

One of my ideas was to expose this whole script as configurable field in launcher. But the part of "contract" is property file. And hard user modifications may end with errors...

Correct, I mean before executing slave.jar. A desired scenario is to run the same version of Jenkins as the master across different platforms.

https://github.com/KostyaSha/yet-another-docker-plugin/blob/98ecf0a17ccbab6ba6913bdb82f97f6de54fb0bb/yet-another-docker-plugin/src/main/java/com/github/kostyasha/yad/launcher/DockerComputerSingleJNLPLauncher.java#L247-L257

We could take advantage of ${parameter:-word} bash parameter expansion. For example, in DockerComputerSingleJNLPLauncher.java you could add to config.sh the following where getJavaPath() is a hypothetical user defined Java executable:

...
"JAVA_PATH=\"" + getJavaPath() + NL +
...

In init.sh you could define:

...
RUN_CMD="${JAVA_PATH:-java}"
...

In the above scenario, if a user defines the JAVA_PATH then it will use that. Otherwise, it will fall back to java which is like the original script.

somehow missed comment. Yes we can try, but then it will be impossible enforce setting when we don't wan't to follow container vars. I think at some point init.sh could be made as extension with chosable things + bind vars...

However you want to do it is fine. I'm just commenting to try to add ideas.