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

User-defined source libraries

    XMLWordPrintable

Details

    Description

      There should be a way for users to define and reuse common fragments of code—libraries, probably in source form (perhaps limited to Groovy).

      When in sandbox mode, the whole program should run in the same secured GroovyShell.

      When using script approval, the administrator should be able to approve the library code independently of any usage.

      Would be useful to integrate with the Git Server plugin so libraries can be readily versioned.

      Attachments

        Issue Links

          Activity

            This would be extremely helpful for us too, as I want to use the code to run from a script, but need the path to that script to use variables not hardcoded as the workspace changes with each execution and we allow for concurrent jobs of this type to run at the same time so you will not know what workspace it is at runtime

            lorelei Lorelei McCollum added a comment - This would be extremely helpful for us too, as I want to use the code to run from a script, but need the path to that script to use variables not hardcoded as the workspace changes with each execution and we allow for concurrent jobs of this type to run at the same time so you will not know what workspace it is at runtime

            As a corollary to an issue I recently created, JENKINS-38796, I'm wondering if there may be some overlap between this issue and mine.

            More precisely, if there were some way an administrator could define a 'safe' location for shared libraries and scripts and allow the content of those files / folders to change without requiring further intervention then I believe the requirements for this improvement would be satisfied as well as providing a mechanism to avoid the problems I've reported on this other issue.

            That being the case I'm wondering if there may be some easy way to implement this change which could be rolled into production sooner rather than later. Based on my admittedly naive understanding of the problem, could you not just add a new button to the script approval page called "approve indefinitely" which, when clicked, simply adds a new entry to the scriptApproval.xml file with the name of the script or class path and an empty value in the 'hash' property indicating that these scripts / libraries / paths are to be loaded regardless of changes that may occur within them after being approved. The verification code could then be modified to simply check to see if the 'hash' value is empty or not, and if it is simply skip comparing the checksum value and automatically approve the script's execution.

            Thoughts?

            leedega Kevin Phillips added a comment - As a corollary to an issue I recently created, JENKINS-38796 , I'm wondering if there may be some overlap between this issue and mine. More precisely, if there were some way an administrator could define a 'safe' location for shared libraries and scripts and allow the content of those files / folders to change without requiring further intervention then I believe the requirements for this improvement would be satisfied as well as providing a mechanism to avoid the problems I've reported on this other issue. That being the case I'm wondering if there may be some easy way to implement this change which could be rolled into production sooner rather than later. Based on my admittedly naive understanding of the problem, could you not just add a new button to the script approval page called "approve indefinitely" which, when clicked, simply adds a new entry to the scriptApproval.xml file with the name of the script or class path and an empty value in the 'hash' property indicating that these scripts / libraries / paths are to be loaded regardless of changes that may occur within them after being approved. The verification code could then be modified to simply check to see if the 'hash' value is empty or not, and if it is simply skip comparing the checksum value and automatically approve the script's execution. Thoughts?
            jglick Jesse Glick added a comment -

            Given the existence of Pipeline and its library system, I have no plans to ever work on this. SecureGroovyScript.classpath is best avoided.

            jglick Jesse Glick added a comment - Given the existence of Pipeline and its library system, I have no plans to ever work on this. SecureGroovyScript.classpath is best avoided.

            People

              jglick Jesse Glick
              jglick Jesse Glick
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: