Executes a Batch script. Multiple lines allowed. When using the returnStdout flag, you probably wish to prefix this with @, lest the command itself be included in the output.

Encoding of process output. In the case of returnStdout, applies to the return value of this step; otherwise, or always for standard error, controls how text is copied to the build log. If unspecified, uses the system default encoding of the node on which the step is run. If there is any expectation that process output might include non-ASCII characters, it is best to specify the encoding explicitly. For example, if you have specific knowledge that a given process is going to be producing UTF-8 yet will be running on a node with a different system encoding (typically Windows, since every Linux distribution has defaulted to UTF-8 for a long time), you can ensure correct output by specifying: encoding: 'UTF-8'

Label to be displayed in the pipeline step view and blue ocean details for the step instead of the step type. So the view is more meaningful and domain specific instead of technical.

Normally, a script which exits with a nonzero status code will cause the step to fail with an exception. If this option is checked, the return value of the step will instead be the status code. You may then compare it to zero, for example.

If checked, standard output from the task is returned as the step value as a String, rather than being printed to the build log. (Standard error, if any, will still be printed to the log.) You will often want to call .trim() on the result to strip off a trailing newline.

Computer name, label name, or any other label expression like linux && 64bit to restrict where this step builds. May be left blank, in which case any available executor is taken.

Supported operators

The following operators are supported, in descending order of precedence:

(expression)

parentheses — used to explicitly define the associativity of an expression

!expression

NOT — negation; the result of expression must not be true

a && b

AND — both of the expressions a and b must be true

a || b

OR — either of the expressions a or b may be true

a -> b

"implies" operator — equivalent to !a || b.
For example, windows -> x64 could be thought of as "if a Windows agent is used, then that agent must be 64-bit", while still allowing this block to be executed on any agents that do not have the windows label, regardless of whether they have also have an x64 label

a <-> b

"if and only if" operator — equivalent to a && b || !a && !b
For example, windows <-> dc2 could be thought of as "if a Windows agent is used, then that agent must be in datacenter 2, but if a non-Windows agent is used, then it must not be in datacenter 2"

Notes

• All operators are left-associative, i.e. a -> b -> c is equivalent to (a -> b) -> c.
• Labels or agent names can be surrounded with quotation marks if they contain characters that would conflict with the operator syntax.
  For example, "osx (10.11)" || "Windows Server".
• Expressions can be written without whitespace, but including it is recommended for readability; Jenkins will ignore whitespace when evaluating expressions.
• Matching labels or agent names with wildcards or regular expressions is not supported.
• An empty expression will always evaluate to true, matching all agents.

Examples

master

This block may be executed only on the Jenkins built-in node

linux-machine-42

This block may be executed only on the agent with the name linux-machine-42 (or on any machine that happens to have a label called linux-machine-42)

windows && jdk9

This block may be executed only on any Windows agent that has version 9 of the Java Development Kit installed (assuming that agents with JDK 9 installed have been given a jdk9 label)

postgres && !vm && (linux || freebsd)

This block may be executed only any on Linux or FreeBSD agent, so long as they are not a virtual machine, and they have PostgreSQL installed (assuming that each agent has the appropriate labels — in particular, each agent running in a virtual machine must have the vm label in order for this example to work as expected)

Executes a Windows PowerShell script (version 3 or later). Multiple lines allowed.

Encoding of process output. In the case of returnStdout, applies to the return value of this step; otherwise, or always for standard error, controls how text is copied to the build log. If unspecified, uses the system default encoding of the node on which the step is run. If there is any expectation that process output might include non-ASCII characters, it is best to specify the encoding explicitly. For example, if you have specific knowledge that a given process is going to be producing UTF-8 yet will be running on a node with a different system encoding (typically Windows, since every Linux distribution has defaulted to UTF-8 for a long time), you can ensure correct output by specifying: encoding: 'UTF-8'

Label to be displayed in the pipeline step view and blue ocean details for the step instead of the step type. So the view is more meaningful and domain specific instead of technical.

Normally, a script which exits with a nonzero status code will cause the step to fail with an exception. If this option is checked, the return value of the step will instead be the status code. You may then compare it to zero, for example.

If checked, standard output from the task is returned as the step value as a String, rather than being printed to the build log. (Standard error, if any, will still be printed to the log.) You will often want to call .trim() on the result to strip off a trailing newline.

Executes a PowerShell script. Multiple lines allowed. This plugin supports PowerShell Core 6+.

Encoding of process output. In the case of returnStdout, applies to the return value of this step; otherwise, or always for standard error, controls how text is copied to the build log. If unspecified, uses the system default encoding of the node on which the step is run. If there is any expectation that process output might include non-ASCII characters, it is best to specify the encoding explicitly. For example, if you have specific knowledge that a given process is going to be producing UTF-8 yet will be running on a node with a different system encoding (typically Windows, since every Linux distribution has defaulted to UTF-8 for a long time), you can ensure correct output by specifying: encoding: 'UTF-8'

Label to be displayed in the pipeline step view and blue ocean details for the step instead of the step type. So the view is more meaningful and domain specific instead of technical.

Normally, a script which exits with a nonzero status code will cause the step to fail with an exception. If this option is checked, the return value of the step will instead be the status code. You may then compare it to zero, for example.

If checked, standard output from the task is returned as the step value as a String, rather than being printed to the build log. (Standard error, if any, will still be printed to the log.) You will often want to call .trim() on the result to strip off a trailing newline.

Runs a Bourne shell script, typically on a Unix node. Multiple lines are accepted.

An interpreter selector may be used, for example: #!/usr/bin/perl

Otherwise the system default shell will be run, using the -xe flags (you can specify set +e and/or set +x to disable those).

Encoding of process output. In the case of returnStdout, applies to the return value of this step; otherwise, or always for standard error, controls how text is copied to the build log. If unspecified, uses the system default encoding of the node on which the step is run. If there is any expectation that process output might include non-ASCII characters, it is best to specify the encoding explicitly. For example, if you have specific knowledge that a given process is going to be producing UTF-8 yet will be running on a node with a different system encoding (typically Windows, since every Linux distribution has defaulted to UTF-8 for a long time), you can ensure correct output by specifying: encoding: 'UTF-8'

Label to be displayed in the pipeline step view and blue ocean details for the step instead of the step type. So the view is more meaningful and domain specific instead of technical.

Normally, a script which exits with a nonzero status code will cause the step to fail with an exception. If this option is checked, the return value of the step will instead be the status code. You may then compare it to zero, for example.

If checked, standard output from the task is returned as the step value as a String, rather than being printed to the build log. (Standard error, if any, will still be printed to the log.) You will often want to call .trim() on the result to strip off a trailing newline.