Archives build output artifacts for later use. As of Jenkins 2.x, you may use the more configurable archiveArtifacts.

Recursively deletes the current directory and its contents. Symbolic links and junctions will not be followed but will be removed. To delete a specific directory of a workspace wrap the deleteDir step in a dir step.

Change current directory. Any step inside the dir block will use this directory as current and any relative path will use it as base path.

Signals an error. Useful if you want to conditionally abort some part of your program. You can also just throw new Exception(), but this step will avoid printing a stack trace.

Checks if the given file (as relative path to current directory) exists. Returns true | false.

Returns true if enclosing node is running on a Unix-like system (such as Linux or Mac OS X), false if Windows.

Simple step for sending email.

Returns the current directory path as a string.

Reads a file from a relative path (with root in current directory, usually workspace) and returns its content as a plain string.

Retry the block (up to N times) if any exception happens during its body execution. If an exception happens on the final attempt then it will lead to aborting the build (unless it is caught and processed somehow). User aborts of the build are not caught.

Simply pauses the Pipeline build until the given amount of time has expired. Equivalent to (on Unix) sh 'sleep …'. May be used to pause one branch of parallel while another proceeds.

Saves a set of files for use later in the same build, generally on another node/workspace. Stashed files are not otherwise available and are generally discarded at the end of the build. Note that the stash and unstash steps are designed for use with small files. For large data transfers, use the External Workspace Manager plugin, or use an external repository manager such as Nexus or Artifactory. This is because stashed files are archived in a compressed TAR, and with large files this demands considerable on-master resources, particularly CPU time. There's not a hard stash size limit, but between 5-100 MB you should probably consider alternatives.

Executes the code inside the block with a determined time out limit. If the time limit is reached, an exception is thrown, which leads in aborting the build (unless it is caught and processed somehow).

Binds a tool installation to a variable (the tool home directory is returned). Only tools already configured in Configure System are available here. If the original tool installer has the auto-provision feature, then the tool will be installed as required.

Restores a set of files previously stashed into the current workspace.

Runs its body repeatedly until it returns true. If it returns false, waits a while and tries again. (Subsequent failures will slow down the delay between attempts.) There is no limit to the number of retries, but if the body throws an error that is thrown up immediately.

Sets one or more environment variables within a block. These are available to any external processes spawned within that scope. For example:

node {
  withEnv(['MYTOOL_HOME=/usr/local/mytool']) {
    sh '$MYTOOL_HOME/bin/start'
  }
}

(Note that here we are using single quotes in Groovy, so the variable expansion is being done by the Bourne shell, not Jenkins.)

See the documentation for the env singleton for more information on environment variables.

This is a special step that allows to call build wrappers (also called "Environment Configuration" in freestyle or similar projects). Just select the wrapper to use from the dropdown list and configure it as needed. Everything inside the wrapper block is under its effect.

Note that only Pipeline-compatible wrappers will be shown in the list.

Prepares an environment for Jenkins to run builds using Apache Ant. Annotates Ant-specific output to display executed targets. Optionally sets up an Ant and/or JDK installation.

This plugin is used to set user build variables:

• BUILD_USER -- full name of user started build,
• BUILD_USER_FIRST_NAME -- first name of user started build,
• BUILD_USER_LAST_NAME -- last name of user started build,
• BUILD_USER_ID -- id of user started build.
• BUILD_USER_EMAIL -- email of user started build.

Enable caching of files on the executor so that subsequent builds do not need to recreate the files. This is helpful for executors that start clean each time such as docker containers.

Caches arbitrary paths on the executor back to the item storage cache.

Make globally configured files available in you local workspace. All files configured via the config-file-provider plugin are available an can be referenced.

This step will use the specified Coverity Tool Installation and add the bin/ directory to PATH for any steps that are wrapped. This will allow the pipeline script to access Coverity tools (like cov-build, cov-analyze, and cov-commit-defects) directly from a script step (such as a Shell Script or Windows Batch Script).

Override the default docker-machine name for this project.
You can use environment variables.
The default value is jenkins-$JOB_NAME, which means a CloudShare environment by the name of docker-machine-jenkins-[job name] would be used (docker-machine- is always prefixed by the docker-machine driver).
Remember to also in configure the CloudShare API keys.

Specify JIRA project key. A project key is the all capitals part before the issue number in JIRA.

(EXAMPLE-100)

Server configurations are created on the Configure System page

Configure Kubernetes client (kubectl) so it can be used in the build to run Kubernetes commands

When enabled, allows masking passwords that may appear in the console.

Passwords or regexes to be masked can be defined at three levels.

First, it is possible to select in Hudson's/Jenkins' configuration screen the build parameters whose value must be masked. For example, selecting the Password Parameter type is a good idea.

Second, still in Hudson's/Jenkins' configuration screen, it is possible to define passwords to be masked as global Name/Password pairs, or regexes to be masked.

Third, on a per job basis (that is, in the current configuration screen), passwords to be masked can be defined as local Name/Password pairs, or regexes can be masked:

• Password is aimed at containing a password to be masked from the console. Empty and blank values are not allowed (e.g. " ", etc.). This field is ciphered. This field can not contain variables, they won't be expanded.
• If Name is set, then a build variable will be defined accordingly. This allows accessing the password by using the variable rather than hard-coding it in a field which is not ciphered (e.g. the ones of the Invoke Ant or Execute shell build steps).
• If Regex is set, then any text matching that regex will be masked in the console output. The regex should not contain start- or end-of-string markers and will be internally and-ed (piped) together with all other regexes and regexes matching the specified names and passwords.

If checked, the Mesos slaves allocated for a build of this job will be used exclusively by the build. Once the build is completed, it will be flagged as offline then disconnected.

If selected, this allows you to define a variable - Jenkins.Repository - that will be present in the Maven environment that points to the specified repository.
The best way of using this is to create a profile in the Jenkins settings.xml:

        <profile>
            <id>jenkins</id>
            <repositories>
                <repository>
                    <id>jenkins</id>
                    <url>${env.Jenkins.Repository}</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                    </snapshots>
                </repository>
            </repositories>
            <pluginRepositories>
                <pluginRepository>
                    <id>jenkins</id>
                    <url>${env.Jenkins.Repository}</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                    </snapshots>
                </pluginRepository>
            </pluginRepositories>
        </profile>

    

This profile is then enabled by adding "-Pjenkins" to your maven build options.

The below properties will be available as build variables in all the build steps during build. You can use them to register test run on your own (in your scripts).

Also the properties set in global plugin configuration ("Dynatrace Application Monitoring" config section) will be available as build variables: 'dtServerUrl', 'dtUsername' and 'dtPassword'.

NOTE:
If you decide not to use the below properties in your scripts and to register test runs on your own, please fill at least the "System profile" field to have the post-build action working properly.

Additional options to be added with the options above to the Xvfb command line.

If checked, Xvnc will be run during this build to provide X display. The X display number will be set to DISPLAY environment variable.

Write the given content to a named file in the current directory.

If the body throws an exception, mark the build as a failure, but nonetheless continue to execute the Pipeline from the statement following the catchError step. This is only necessary when using certain post-build actions (notifiers) originally defined for freestyle projects which pay attention to the result of the ongoing build.

node {
    catchError {
        sh 'might fail'
    }
    step([$class: 'Mailer', recipients: 'admin@somewhere'])
}

If the shell step fails, the Pipeline build’s status will be set to failed, so that the subsequent mail step will see that this build is failed. In the case of the mail sender, this means that it will send mail. (It may also send mail if this build succeeded but previous ones failed, and so on.) Even in that case, this step can be replaced by the following idiom:

node {
    try {
        sh 'might fail'
    } catch (err) {
        echo "Caught: ${err}"
        currentBuild.result = 'FAILURE'
    }
    step([$class: 'Mailer', recipients: 'admin@somewhere'])
}

For all other cases, use plain try-catch(-finally) blocks:

node {
    sh './set-up.sh'
    try {
        sh 'might fail'
        echo 'Succeeded!'
    } catch (err) {
        echo "Failed: ${err}"
    } finally {
        sh './tear-down.sh'
    }
    echo 'Printed whether above succeeded or failed.'
}
// …and the pipeline as a whole succeeds

See this document for background.