Details

    • Similar Issues:

      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

            Hide
            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

            Show
            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
            Hide
            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?

            Show
            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?
            Hide
            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.

            Show
            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

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

                Dates

                • Created:
                  Updated:
                  Resolved: