I have some Groovy scripts that worked just fine in Jenkins 1.x but are now broken in 2.x. This is actually blocking my update, so I would be grateful for any suggestions on how to proceed.
I execute a system Groovy script in a post build step. The script is executed from the main instance or a node like so:
/var/www/jenkins-groovy-helpers/JenkinsBuildHelper/UniwersalBuildChecker.groovy
I already used Permissive Script Security to try and disable additional security added in Jenkins 2.x (which honestly I don’t need as I’m the only person editing jobs).
Can I load a groovy class in some other way? Or maybe I can enable some standalone/single-user/single-admin mode or something that disables all this security checks?
As you can imagine BuildLogChecker is used to check log, but also needs access to job description as it sets descriptions based on errors in the job log (build.setDescription(...)). It also sets results:
if (!buildLogChecker.firstLogLines.error.isEmpty()) {
build.setResult(Result.FAILURE);
} else if (!buildLogChecker.firstLogLines.warn.isEmpty()) {
build.setResult(Result.UNSTABLE);
}
Jenkins setup:
Jenkins: 2.401.3
OS: Linux - 5.15.0-78-generic
Java: 17.0.7 - Private Build (OpenJDK 64-Bit Server VM)
It’s a freestyle job. I actually have a lot of jobs using this script.
The message from Jenkins 2.x says:
[PostBuildScript] - [INFO] Executing post build scripts.
ERROR: Build step failed with exception
groovy.lang.MissingMethodException: No signature of method: java.lang.Class.newInstance() is applicable for argument types: (java.util.LinkedHashMap) values: [[ignoreMode:false, ignoreLevels:, maxLevel:error]]
Possible solutions: newInstance(), newInstance(), newInstance([Ljava.lang.Object;), isInstance(java.lang.Object)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:159)
I’m running a script from a file and the file is common for a lot of jobs. I don’t have the Sandbox option for running a file (only for runing Groovy command)
You probably should consider switching to modern and supported ways to achieve your goals instead ( as you did a extremly huge jump in versions, actually over 8 years in time). I recommend switching to use the warningsng plugin to do any build log evaluation.
Hmm… It sounds like running Groovy scripts is no longer a viable option, and I need to create plugins instead. Or am I missing the point?
Security-wise, this seems a bit concerning. If users can edit jobs, they can potentially add shell scripts that could cause more damage than just breaking a Jenkins installation. While you can set up Jenkins nodes with a DMZ for strict security, it’s not required by Jenkins and admin can decide on what is safe. Blocking execution of Groovy scripts in a specific way without a clear opt-out option, while keeping shell script executions free, seems like a peculiar move (since both basically have the same security risks).
The article below only confirms my fears that once you allow certain functions, they are permitted in all jobs to be used in any way, rather than just allowing the execution of specific scripts that the admin confirmed were safe. And it seems, it is no longer possible to perform maintenance of Jenkins from within Jenkins using Groovy scripts, right? Or did any of this improve since 2017?
system groovy scripts still work in latest Jenkins (I’m making heavy use of this). It might be just your specific use case with trying to load a groovy script from within another groovy script that is broken. This might be related to having a newer groovy packaged now compared to your old Jenkins.
we have thousands of jobs, that is impossible to maintain by hand. So we have a generator for the jobs (proprietary solution). But you can also use JobDSL to manage the jobs.
But most jobs don’t need any groovy on our side.
If I would have to start over again I would try to make use of pipeline and have the common parts moved into a shared library.
