Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-15210

Add variable resolution to "additional groovy class path"

    Details

    • Similar Issues:

      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.

        Attachments

          Issue Links

            Activity

            Hide
            sschuberth Sebastian Schuberth added a comment -

            @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.

            Show
            sschuberth Sebastian Schuberth added a comment - @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.
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - An alternative solution would be to extend script-security with a reusable scripts repository – that way, it can be controlled by Jenkins admins.
            Hide
            ikedam ikedam added a comment -

            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.

            Show
            ikedam ikedam added a comment - 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.
            Hide
            sschuberth Sebastian Schuberth added a comment -

            @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.

            Show
            sschuberth Sebastian Schuberth added a comment - @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.
            Hide
            danielbeck Daniel Beck added a comment -

            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).

            Show
            danielbeck Daniel Beck added a comment - 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).

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                danielbeck Daniel Beck
              • Votes:
                6 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: