The following plugin provides functionality available through Pipeline-compatible steps. Read more about how to integrate steps into your Pipeline in the Steps section of the Pipeline Syntax page.
For a list of other such plugins, see the Pipeline Steps Reference page.
bat
: Windows Batch Scriptscript : String
returnStdout
flag, you probably wish to prefix this with @
, lest the command itself be included in the output.
encoding : String
(optional)
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 : String
(optional)
returnStatus : boolean
(optional)
returnStdout : boolean
(optional)
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.
node
: Allocate nodelabel : String
linux && 64bit
to restrict where this step builds. May be left blank, in which case any available executor is taken.
powershell
: Windows PowerShell Scriptscript : String
encoding : String
(optional)
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 : String
(optional)
returnStatus : boolean
(optional)
returnStdout : boolean
(optional)
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.
pwsh
: PowerShell Core Scriptscript : String
encoding : String
(optional)
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 : String
(optional)
returnStatus : boolean
(optional)
returnStdout : boolean
(optional)
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.
sh
: Shell Scriptscript : String
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 : String
(optional)
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 : String
(optional)
returnStatus : boolean
(optional)
returnStdout : boolean
(optional)
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.
ws
: Allocate workspacenode
step.
dir : String
A workspace is automatically allocated for you with the node
step, or you can get an alternate workspace with this ws
step, but by default the location is chosen automatically. (Something like AGENT_ROOT/workspace/JOB_NAME@2
.)
You can instead specify a path here and that workspace will be locked instead. (The path may be relative to the build agent root, or absolute.)
If concurrent builds ask for the same workspace, a directory with a suffix such as @2
may be locked instead. Currently there is no option to wait to lock the exact directory requested; if you need to enforce that behavior, you can either fail (error
) when pwd
indicates that you got a different directory, or you may enforce serial execution of this part of the build by some other means such as stage name: '…', concurrency: 1
.
If you do not care about locking, just use the dir
step to change current directory.
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.