[JIRA] (JENKINS-15210) Allow "additional groovy class path" to reference workspace

280 views
Skip to first unread message

daniel@beckweb.net (JIRA)

unread,
Sep 18, 2012, 4:41:49 AM9/18/12
to jenkinsc...@googlegroups.com
Issue Type: Improvement Improvement
Affects Versions: current
Assignee: wolfs
Components: groovy-postbuild
Created: 18/Sep/12 8:41 AM
Description:

Some of my Groovy postbuild scripts are rather long due to rather complex information gathering and presentation, and I'd like to store them in SVN to get a proper version history. It'd be great if that version would be recorded alongside everything else about the build.

Currently it's only possible to specify a full absolute path as "additional groovy class path". There is no variable substitution for e.g. $WORKSPACE, and relative paths don't resolve within the workspace. As I'm trying to get rid of absolute paths as much as possible (tool auto installation, working in workspace only, etc.), this is a step backwards.

Please add this feature to allow storing scripts in SVN and having them check out to e.g. $WORKSPACE/gpb and record the revision information for them there.

Project: Jenkins
Priority: Major Major
Reporter: Daniel Beck
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

daniel@beckweb.net (JIRA)

unread,
Sep 19, 2012, 11:21:50 AM9/19/12
to jenkinsc...@googlegroups.com
Daniel Beck commented on Improvement JENKINS-15210

On further thought, using $WORKSPACE breaks in a master/slave scenario, as postbuild is executed on the master. But variable resolution would still allow the global definition of an environment variable such as GROOVY_POSTBUILD_SCRIPTS_DIR and reusing that in the individual jobs – an improvement upon the current situation.

daniel@beckweb.net (JIRA)

unread,
Sep 20, 2012, 3:54:49 AM9/20/12
to jenkinsc...@googlegroups.com
Change By: Daniel Beck (20/Sep/12 7:54 AM)
Summary: Allow Add variable resolution to  "additional groovy class path"  to reference workspace
Description:
Some of my Groovy postbuild scripts are rather long due to rather complex information gathering and presentation, and I'd like to store them in SVN to get a proper version history. It'd be great if that version would be recorded alongside everything else about the build.

Currently it's only possible to specify a full absolute path as "additional groovy class path". There is no variable substitution for e.g. {{$WORKSPACE}}  or Jenkins/node level environment variables , and relative paths don't resolve within the workspace. As I'm trying to get rid of absolute paths as much as possible (tool auto installation, working in workspace only, etc.), this is a step backwards.

Please add this feature to allow storing scripts in SVN and having them check out to e.g. {{$WORKSPACE/gpb}}
 or {{$GROOVY_POSTBUILD_SCRIPTS}} (defined for each node)  and record the revision information for them there.

martin.danjou14@gmail.com (JIRA)

unread,
May 15, 2014, 9:42:04 AM5/15/14
to jenkinsc...@googlegroups.com

martin.danjou14@gmail.com (JIRA)

unread,
Jun 16, 2014, 11:01:04 AM6/16/14
to jenkinsc...@googlegroups.com

Using $WORKSPACE works in a network where the master and the slaves have have the same mounted file systems (e.g. NFS). So the ability to use $WORKSPACE is an improvement over using a hardcoded class path.

martin.danjou14@gmail.com (JIRA)

unread,
Jul 16, 2014, 7:18:22 PM7/16/14
to jenkinsc...@googlegroups.com

Hi,

I want to provide a clear series of steps to reproduce this bug because as I was reproducing it, I ran into a another possibly related problem. I use Jenkins 1.532.3. The steps to reproduce are:

Install Jenkins with the Groovy Postbuild plugin, restart Jenkins
I have downloaded jenkins.war to my ~/Downloads folder on linux (this is important, see below).
Create a freestyle job
Add a build step: Execute shell

Set the content of the shell to:

#!/bin/bash

# wipe out the workspace
rm -rf *

# Create a groovy script for postbuild
mkdir -p subfolder
printf "class PostBuild {
  def manager
  def PostBuild(manager) {
    this.manager = manager
  }
  def run() {
    println('Done')
  }
}
" >subfolder/PostBuild.groovy

Add a Post-build action or type "Groovy Postbuild"

Set the Groovy script to:

import PostBuild
def postBuild = new PostBuild(manager)
postBuild.run()

Set the additional groovy classpath to: $WORKSPACE/subfolder

Save the job, and run it.

The job will fail to resolve the class PostBuild because the $WORKSPACE variable is not expanded.

Additional details
Now go back and edit the job configuration again. Examine the value of the classpath again: Jenkins has changed it to /home/username/Downloads/$WORKSPACE/subfolder. This is rather unexpected. Is this because jenkins.war was installed in /home/username/Downloads? I think the classpath should not be modified by the plugin.

So I think this issue consists of is one bug and one feature request:

  • Feature request: The $WORKSPACE variable should be expanded
  • Bug: Jenkins re-writes the additional groovy classpath to /home/username/Downloads/$WORKSPACE/subfolder, but it should leave the classpath alone after it has been set by the user.

Lastly, the plugin does not support multiple colon separated classpath values. When I move the PostBuid.groovy script to say /home/username/groovyLib, and I set the classpath to /home/username/groovyLib:/home/username/otherLib then the plugin is unable to evaluate the groovy script. If the plugin was intended to support multiple classpath values, then this is also a bug.

kevin.trizna@spcapitaliq.com (JIRA)

unread,
Jul 28, 2014, 4:12:55 PM7/28/14
to jenkinsc...@googlegroups.com

I am a contributor to this plugin who plays a slightly smaller role than most, but I see how I could go about coding this. Assuming nobody else has picked this up, I'll go ahead and sponsor this.

kevin.trizna@spcapitaliq.com (JIRA)

unread,
Jul 30, 2014, 6:55:53 PM7/30/14
to jenkinsc...@googlegroups.com
 
Kevin Trizna edited a comment on Improvement JENKINS-15210

I am a contributor to this plugin who plays a slightly smaller role than most, but I see how I could go about coding this. I'm currently working on it, I'll update you if I ever find a way to integrate this.

martin.danjou14@gmail.com (JIRA)

unread,
Sep 3, 2014, 4:08:56 PM9/3/14
to jenkinsc...@googlegroups.com

martin.danjou14@gmail.com (JIRA)

unread,
Sep 3, 2014, 4:09:00 PM9/3/14
to jenkinsc...@googlegroups.com

sschuberth@gmail.com (JIRA)

unread,
Sep 4, 2014, 11:05:20 AM9/4/14
to jenkinsc...@googlegroups.com

Looks like addressing this would possibly interfere with the pending pull request to integrate with the Script Security plugin [1]. I've posted a comment / question to the PR to get some more details.

[1] https://github.com/jenkinsci/groovy-postbuild-plugin/pull/11

sschuberth@gmail.com (JIRA)

unread,
Sep 4, 2014, 11:05:22 AM9/4/14
to jenkinsc...@googlegroups.com

BTW, as a work-around, it should be possible to use Groovy's evaluate() [1] instead of tampering with the classpath.

[1] http://stackoverflow.com/a/9154553/1127485

devld@ikedam.jp (JIRA)

unread,
Sep 20, 2014, 9:06:26 PM9/20/14
to jenkinsc...@googlegroups.com

Changed component to script-security plugin as the classpaths resolution is done by Script Security plugin since groovy-postbuild 2.0 .

I think this feature assumes to use libraries generated in builds.
It's not generally secure, and should not be allowed.
It should be run with another JVM instance, that is, you should launch new java processes.

@jglick
Can you have a look at this?
I think this can be closed with "Won't Fix".

Change By: ikedam (21/Sep/14 1:05 AM)
Assignee: wolfs Jesse Glick
Component/s: script-security
Component/s: groovy-postbuild

sschuberth@gmail.com (JIRA)

unread,
Sep 21, 2014, 3:02:25 AM9/21/14
to jenkinsc...@googlegroups.com

@ikedam As outlined in the initial comment, this is not about adding libraries generated in builds to classpath. It's about storing (large) Groovy files for Jenkins in the VCS, along with the code that is supposed to be built. Basically, you just store the instructions how to build along with what to build, which IMHO makes very much sense.

daniel@beckweb.net (JIRA)

unread,
Sep 21, 2014, 5:54:25 AM9/21/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Improvement JENKINS-15210

An alternative solution would be to extend script-security with a reusable scripts repository – that way, it can be controlled by Jenkins admins.

devld@ikedam.jp (JIRA)

unread,
Sep 21, 2014, 6:47:24 AM9/21/14
to jenkinsc...@googlegroups.com
ikedam commented on Improvement JENKINS-15210

Sorry, I misunderstood the problem.
Anyway, it requires approaches other than using variables as jar files in workspaces shouldn't work correct in distributed builds.

I agree with @danielbeck.
It's often the case users want to reuse a script in multiple projects.

sschuberth@gmail.com (JIRA)

unread,
Sep 21, 2014, 3:39:24 PM9/21/14
to jenkinsc...@googlegroups.com

@danielbeck A reusable scripts repository basically is what the Scriptler plugin already provides, no? In fact, that's exactly what we do as a work-around currently: We manually copy our private Groovy postbuild scripts to the Scriptler directory, which is in classpath, in order to share common code between postbuild steps.

daniel@beckweb.net (JIRA)

unread,
Sep 21, 2014, 3:57:24 PM9/21/14
to jenkinsc...@googlegroups.com
Daniel Beck commented on Improvement JENKINS-15210

Sebastian Schuberth It's only available to admins though (and users with Run Scripts permission, which as standalone permission is actually more powerful than Administer, but the Scriptler docs pretend it's not).

jglick@cloudbees.com (JIRA)

unread,
Sep 22, 2014, 8:57:24 AM9/22/14
to jenkinsc...@googlegroups.com
Jesse Glick resolved Improvement JENKINS-15210 as Duplicate
Change By: Jesse Glick (22/Sep/14 12:56 PM)
Status: Open Resolved
Resolution: Duplicate
Reply all
Reply to author
Forward
0 new messages