Details
-
New Feature
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Won't Do
-
None
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
- is duplicated by
-
JENKINS-15210 Add variable resolution to "additional groovy class path"
-
- Resolved
-
- is related to
-
-
- Resolved
-
Activity
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?
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? Given the existence of Pipeline and its library system, I have no plans to ever work on this. SecureGroovyScript.classpath is best avoided.
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