java_image: launcher tool/script support
The ability to alter java_image entrypoint without losing classpath information
Relevant Rules
This would be a change/addition to java_image.
Description
The java_image rule makes it possible to pass extra arguments to the JVM via the jvm_flags attribute, but that's not always sufficient. In our case we'd like to replace the hardcoded /usr/bin/java part of the entrypoint with a custom bash script.
Describe the solution you'd like
There are a couple of ways we could go about this:
(1) a new attr to jar_app_layer (jvm_binary or launcher) that would allow us to replace /usr/bin/java with our custom launcher script,
(2) have the java_image macro emit a name + ".classpath" target that contains the contents of the classpath. That way we could "wrap" the java_image with container_image(base=":java_img", entrypoint="/bin/bash launcher.sh $(location :java_img.classpath", ...),
(3) have java_image export a CLASSPATH variable (via TemplateVariableInfo or some custom provider) and have container_image consume that via base. That way we could "wrap" the java_image with container_image(base=":java_img", entrypoint="/bin/bash launcher.sh $CLASSPATH", ...)
Out of these options I'd be very happy to send a PR for any of them. I don't have much experience hacking rules_docker so guidance here would be appreciated. To me (2) seems like the most reasonable approach. (1) is simple but pollutes the API, (3) seems elegant, but would require container_image to run expand_make_variables on the entrypoint and thus cost some extra CPU.
Describe alternatives you've considered
Wrapping the java_image target with a container_image (which has the original java_image as base), except that only allows us to replace the entrypoint and so the classpath information from the java_image is lost.
It's possible to specify classpath_as_file and that also gets us pretty close, however we don't have a reliable way of computing the location of the classpath file, so we'd need to run find to locate it.
Actually, thinking about (2) a bit more, that would require adding :java_img.classpath to the container_image via the files attribute, making the API slightly more complex than what I originally suggested.
For (3), if we made CLASSPATH available as an make-style variable in the env instead (container_image(.. env = {"CLASSPATH": "$(CLASSPATH)"}, ..) that would remove the extra cost as make-style variable expansion is already done for the env attr.
This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!
This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"
We have a similar issue to this - we want to replace node with nodemon, for example, in JS rules.