Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Wiki Markup

This plugin adds the ability to directly execute Groovy code.


To configure available Groovy installation on your system, go to Hudson Jenkins configuration page, find section 'Groovy' and fill the form as shown bellow.

If you don't configure any Groovy installation and select (Default) option in a job, the plugin will fallback into calling just the groovy command, assuming you have groovy binary on the default path on given machine.


To create Groovy-based project, add new free-style project and select "Execute Groovy script" in the Build section, select previously configured Groovy installation and then type your command, or specify your script file name. In the second case path taken is relatively from the project workspace directory.

Jenkins 1.x:

Jenkins 2.x:

Jenkins 2.xImage Added

The plugin also adds the functionality of the Script Console to the project configuration page.

You can schedule your system management script...

Image RemovedImage Added

...and then observe progress in the build log.

Image RemovedImage Added

Groovy Script vs System Groovy Script

The plain "Groovy Script" is run in a forked JVM, on the slave where the build is run. It's the basically the same as running the "groovy" command and pass in the script.

The system groovy script, OTOH, Groovy script on the other hand runs inside the Hudson Jenkins master's JVM. Thus it will have access to all the internal objects of HudsonJenkins, so you can use this to alter the state of HudsonJenkins. It is similar to the Jenkins Script Console functionality.


System groovy jobs has access to whole Jenkins, therefore only users with admin rights can  add add system groovy Groovy build step and configure the system groovy Groovy script. Permissions are not checked when the build is triggered (i.e. also uses without admin rights can also run the script). The idea is to allow users run some well defined (defined by admin) system tasks when they need it (e.g. put slave offline/online, when user wants to start some debugging on slave). To have Jenkins instance secure, the support for Token macro plugin has to be switched off, see section bellowbelow.

Token macro plugin support

Groovy plugin provides support for  Token Macro Plugin. Expression is GROOVY with parameter script:

No Format

${GROOVY,script = "return hudson.model.Hudson.instance.pluginManager.plugins"}


Execute a system Groovy script like:

Code Block

import hudson.model.*
import hudson.AbortException
import hudson.console.HyperlinkNote
import java.util.concurrent.CancellationException

// Retrieve parameters of the current build
def build = Thread.currentThread().executable
def foo = build.buildVariableResolver.resolve("FOO")
println "FOO=$foo"

// Start another job
def job = Hudson.instance.getJob('MyJobName')
def anotherBuild
try {
    def params = [
      new StringParameterValue('FOO', foo),
    def future = job.scheduleBuild2(0, new Cause.UpstreamCause(build), new ParametersAction(params))
    println "Waiting for the completion of " + HyperlinkNote.encodeTo('/' + job.url, job.fullDisplayName)
    anotherBuild = future.get()
} catch (CancellationException x) {
    throw new AbortException("${job.fullDisplayName} aborted.")
println HyperlinkNote.encodeTo('/' + anotherBuild.url, anotherBuild.fullDisplayName) + " completed. Result was " + anotherBuild.result

// Check that it succeeded
build.result = anotherBuild.result
if (anotherBuild.result != Result.SUCCESS && anotherBuild.result != Result.UNSTABLE) {
    // We abort this build right here and now.
    throw new AbortException("${anotherBuild.fullDisplayName} failed.")

// Do something with the output.
// On the contrary to Parameterized Trigger Plugin, you may now do something from that other build instance.
// Like the parsing the build log (see )
// You probably may also wish to update the current job's environment.
build.addAction(new ParametersAction(new StringParameterValue('BAR', '3')))


To retrieve properties defined in the Properties field use:

Code Block



Upcomming changes

Usage with pipeline

Currently the plugin does not support pipeline syntax. One workaround from Unknown User (alexander_samoylov) was mentioned here:


Release 2.2 (2019-03-06)
Release 2.1 (2019-01-28)
Release 2.0 (2017-04-10)
  • Arbitrary code execution by unprivileged user (SECURITY-292)
  • continue with code cleanup - fixed Findbugs issues
Release 1.30 (2016-11-18)
  • XSS protection
  • code cleanup
Release 1.28, 1.29 (2016-01-05)
  • code cleanup
Release 1.27 (2015-08-05)
  • Callable roles are properly checked
Release 1.26 (2015-07-27)
Release 1.25 (2015-05-11)
  • Made default choice also for System Groovy script to avoid zero height of textarea (JENKINS-25455)
  • Add help file for Groovy version (JENKINS-12988)
  • Made setting Groovy installations thread-safe (JENKINS-28287)
Release 1.24 (2014-11-09)
  • Ensure non-zero height of Groovy command text box, making it default choice when adding new build step (JENKINS-25455)
Release 1.23 (2014-10-27)
Release 1.22 (2014-09-30)
Release 1.21 (2014-09-18)
Release 1.20 (2014-07-30)
  • Unable to specify multiple jars on class path for a system groovy script (JENKINS-23997)
Release 1.19 (2014-07-07)
Release 1.18 (2014-05-13)
Release 1.17 (2014-05-09)
  • Allow whitespaces in properties (passed via -D switch) (pull13)
Release 1.16 (2014-04-07)
Release 1.15 (2014-01-31)
  • Syntax highlighting
  • Syntax validation button
  • Prepare for Jenkins core upgrade to Groovy 2.x (pull9)
Release 1.14 (2013-07-02)
  • Right to run the System Groovy script changed from ADMINISTER to RUN_SCRIPTS (pull7)
Release 1.13 (2013-03-01)
  • Added build context (build, launcher, listener) into system groovy build step (pull6)