Groovy plugin disable sandbox for System Groovy Script and Groovy script file

Hi all,
I am automating some logic with a groovy script and I thought I could run it periodically directly from Jenkins.
I have created a freestyle project and installed the groovy plugin to do so: Groovy.
Since I need to access internal objects of Jenkins such as credentials and managed files I am using the System Groovy Script option provided by the plugin.
This option allows for to specify a Groovy command and a Groovy script file. The Groovy command option allows to disable or enable the Sandbox while for some reasons the Groovy script file does not have such option.
My script works fine when running it with the Groovy command option but fails with the Groovy script file complaining about @Grab not being secure (I use it download some dependencies).
I really would like to use the Groovy script file option as it easily allow me to clone the repository where the script will be saved and then run the main script file. Moreover it allows for splitting the logic into different files.
I tried some hacks with the Groovy command option as well, such us running:

evaluate(new File("${WORKSPACE}/MyScript.groovy"))

but apparently the workspace variable is not available in a freestyle project…

Any suggestions?.

Thanks,
Giovanni

FYI, I’m encountering exactly the same issue. Has anyone come across a decent fix for this?

It sounds like you’re trying to run a Groovy script that needs to access internal Jenkins objects and system libraries, and you’re encountering issues with the “@Grab” annotation when using the Groovy script file option. The reason for this is that the Groovy sandboxing mechanism in Jenkins restricts the usage of certain classes and operations to prevent potentially unsafe or disruptive behavior. :person_shrugging:

When using the Groovy script file option, Jenkins runs your script with the security constraints of the Jenkins Groovy sandbox. This restricts your script from performing operations that could be considered unsafe, such as using the “@Grab” annotation to download external dependencies or accessing internal Jenkins objects directly.

One way of working around this would be to create a shared library… maybe?