groovy plugin?
Les Mikesell
I can run the example 'println System.getenv("PATH")' in the jenkins
script console for a slave but if I put the same thing in an 'execute
groovy script''s groovy command box and run a build I get:
[envtest] $ groovy e:\hudson\workspace\envtest\hudson782241948209548068.groovy
The system cannot find the file specified
FATAL: command execution failed
java.io.IOException: Cannot run program "groovy" (in directory
"e:\hudson\workspace\envtest"): CreateProcess error=2, The system
cannot find the file specified
at java.lang.ProcessBuilder.start(Unknown Source)
[...]
(default) is the only option for the groovy version.
--
Les Mikesell
lesmi...@gmail.com
Vojtech Juranek
there are two options, groovy script and system groovy script. First one
requires groovy installation on slaves (check global jenkins configuration,
auto-install can be used), second doesn't, however it's not executed on slave,
but in master JVM (it uses bundled groovy lib in the same way as you run
groovy script via groovy console)
Les Mikesell
>> Does the groovy plugin need anything special installed on the slaves?
>
> there are two options, groovy script and system groovy script. First one
> requires groovy installation on slaves (check global jenkins configuration,
> auto-install can be used), second doesn't, however it's not executed on slave,
> but in master JVM (it uses bundled groovy lib in the same way as you run
> groovy script via groovy console)
I don't get it. The script console in the node screen works and runs
on the slaves. For example I can run 'println "ipconfig
/all".execute().text and I get results that are obviously coming from
the windows slave even though the jenkins server and master jvm are on
linux. Or is that remoted with some java magic?
I checked the auto-install option but it doesn't seem to make any
difference. Should the attempt to install be logged somewhere so I
can see if it failed?
--
Les Mikesell
lesmi...@gmail.com
Vojtech Juranek
wrote:
> >> Does the groovy plugin need anything special installed on the slaves?
> >
> > there are two options, groovy script and system groovy script. First one
> > requires groovy installation on slaves (check global jenkins
> > configuration, auto-install can be used), second doesn't, however it's
> > not executed on slave, but in master JVM (it uses bundled groovy lib in
> > the same way as you run groovy script via groovy console)
>
> I don't get it. The script console in the node screen works and runs
> on the slaves. For example I can run 'println "ipconfig
> /all".execute().text and I get results that are obviously coming from
> the windows slave even though the jenkins server and master jvm are on
> linux. Or is that remoted with some java magic?
exactly, slave agent has remote class loader which is able to load all
necessary classes from master (if you are interested in technical details, see
[1]). If you consider similar function/build step useful, please file a feature
JIRA request for me, it shouldn't be very difficult to implement it.
> I checked the auto-install option but it doesn't seem to make any
> difference. Should the attempt to install be logged somewhere so I
> can see if it failed?
installation should be visible in the log (in log of the build which tries to
install groovy before launching groovy commands). Could you provide some
details or log a JIRA for it if you think it's a bug?
Thanks
Les Mikesell
I was just missing something obvious. Along with checking the
'Install automatically' box in the global config (which might have
been set by default) you have to give it a name and then you have to
pick that name in the job config. Before getting this right, the job
config only offered the 'default' verision, and until I went back to
the job and changed it, it didn't trigger the install. And until I
clicked the drop-down on in the job config I don't realize there was a
new option there.
--
Les Mikesell
lesmi...@gmail.com
Vojtech Juranek
> I was just missing something obvious. Along with checking the
> 'Install automatically' box in the global config (which might have
> been set by default) you have to give it a name and then you have to
> pick that name in the job config. Before getting this right, the job
> config only offered the 'default' verision, and until I went back to
> the job and changed it, it didn't trigger the install. And until I
> clicked the drop-down on in the job config I don't realize there was a
> new option there.
thanks for feedback, IIRC this is standard behavior of any auto-installer, but
I'll check if I missed something somewhere
Les Mikesell
It makes sense now, but since I didn't understand it at first I set up
a job with the 'default' groovy version which was the only choice, and
it continued to fail after giving the install a name. It would have
helped to mention that the version names had to match in the ? help
link in the main and job configs where you enter them. Or maybe even
to make the 'default' choice work with the auto-installed copy if you
don't find one earlier in PATH. Shouldn't that become the default if
there is no other?
--
Les Mikesell
lesmi...@gmail.com
Vojtech Juranek
Yes, make sense, thank. Logged as JENKINS-12988 [1].
As for "default" - it's defined as calling "groovy" command - i.e. it calls the
installation which you have as the first on the path. In some cases such setup
can be useful, second problem is backward compatibility. So the only possible
solution which has come to my mind so far is to keep this behavior and switch
to some installation defined in global Jenkins config only if calling "groovy"
fails - i.e. there's no groovy in the path. Does it make sense?
Another possibility could be to add some checkbox which would allow users to
define "default" installation in global jenkins config (as the user
intentionally select the "default", he wants to change "default" behavior, so
there shouldn't be a problem with backward compatibility).
Logged as JENKINS-12989 [2], feel free to add comments.
Thanks
[1] https://issues.jenkins-ci.org/browse/JENKINS-12988
[2] https://issues.jenkins-ci.org/browse/JENKINS-12989