I'm not really sure what you are asking here, how did you call these scripts before?
A Pipeline Shared Groovy Librariy that is trusted is able to call any Jenkins api since it is not running in the sandbox, although still running in CPS, but should still be able to call for example RemotingDiagnostics.executeGroovy even though it is a biig security risk to do so. The scriptler plugin has a library feature iirc that can also be run as a build step. /B On Sun, May 7, 2017 at 3:09 PM, 'Bruno P. Kinoshita' via Jenkins Developers <[email protected]> wrote: > +1 Andreas > > > Wanting the same right now. Started a small sandbox [1] some time ago to > try understand everything I would need for active-choices, but got > distracted by security and performance issues. > > * Execute a Groovy script > * Allow user to add extra jars > * Graple dependency management support > * Option to enable script-security integration (on by default) > > The Groovy execution layer in active-choices came from > dynamicparameter-plugin, then was a bit tweaked. Later we added > script-security. Now need to look into extra jars (right now integrating > ImageJ). > > Cheers > Bruno > [1] https://github.com/kinow/groovy-script-lib > > ________________________________ > From: Andreas Mandel <[email protected]> > To: Jenkins Developers <[email protected]> > Sent: Sunday, 7 May 2017 10:14 PM > Subject: Pipeline Shared Groovy Libraries and system groovy script > classpath > > > > Hi List, > > since the last security updates, a common practice to work with system > groovy scripting does not work any more. It might be easily resolvable with > a small(?) change in the Pipeline Shared Groovy Libraries plugin. > > We have a lot of system groovy scripts in Jenkins jobs that take care for > cleanup, monitoring, etc. These jobs check out certain scripts from SCM and > then call them as a system groovy script. With the recent changes, you > cannot simply add and call something "dynamic" in the workspace as system > groovy script anymore. I do not want to go a step back and put the whole > code inside the Jenkins job definition. > > On the other hand with the Pipeline Shared Groovy Libraries plugin we now > have a quite powerful library management plugin for groovy libraries. > Unfortunately as of now this only works for pipeline jobs and not for the > use in system groovy scripts. > > Would it be possible to add a functionality to mark a library in the > Pipeline Shared Groovy Libraries plugin as "system groovy library" and so > make it available on the class path of any system groovy script? > > Could this work out? How are other resolving this topic? > > > Thanks, > Kind Regards, > Andreas. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/c3537dfe-c206-428d-9e3a-7a298d98a785% > 40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/800881429.5606274.1494162579878%40mail.yahoo.com. > For more options, visit https://groups.google.com/d/optout. > -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS17z8QtaLw791d19TahXDtCez0_zOPHAWXatuytAV4qgQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
