-
Bug
-
Resolution: Not A Defect
-
Minor
-
None
-
Docker image "jenkins:latest", 3f08dc4f3f5d, Jenkins 2.60.3
I just did a test with the default docker Jenkins image "jenkins:latest". I installed the two plugins Groovy 2.0 and Groovy Postbuild 2.3.1 in it. I created a simple freestyle build job which has build steps for the two plugins. When running the job, I see the following error message in the console from the "Groovy Step", while the "Groovy Postbuild Step" successfully ran:
java.io.IOException: Cannot run program "groovy" (in directory "/var/jenkins_home/workspace/test"): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at hudson.Proc$LocalProc.<init>(Proc.java:245) at hudson.Proc$LocalProc.<init>(Proc.java:214) at hudson.Launcher$LocalLauncher.launch(Launcher.java:850) at hudson.Launcher$ProcStarter.start(Launcher.java:384) at hudson.Launcher$ProcStarter.join(Launcher.java:395) at hudson.plugins.groovy.Groovy.perform(Groovy.java:106) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:735) at hudson.model.Build$BuildExecution.build(Build.java:206) at hudson.model.Build$BuildExecution.doRun(Build.java:163) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:490) at hudson.model.Run.execute(Run.java:1735) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:405) Caused by: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.<init>(UNIXProcess.java:247) at java.lang.ProcessImpl.start(ProcessImpl.java:134) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) ... 15 more
Problem: The docker image doesn't contain a "groovy" binary.
Main Problem: The (working) Postbuild plugin shows that a groovy binary is not necessary. Obviously, it the plugin has a better implementation and uses an internal library while the "Groovy Plugin" uses an external binary and thus has an extra dependency.
Demand: Most likely, the internal library implementation is much more efficient and better integrated than the external variant, so I recommend to copy code from the "Groovy Postbuild Plugin" to the "Groovy Plugin" so that both have the same dependencies - or even better: implement normal build steps as additional feature in the "Groovy Postbuild Plugin" (and possibly rename it) and mark the "Goovy Plugin" as deprecated