Snippet Generator

Declarative Directive Generator

Declarative Online Documentation

Steps Reference

Global Variables Reference

Online Documentation

Examples Reference

IntelliJ IDEA GDSL

Overview

A quick example:

node {
    sh 'echo hello world'
}

You can write any Groovy code you need, using Java API calls plus the GDK. You can also call Jenkins APIs and APIs in Jenkins plugins. (If Use Groovy Sandbox is checked, or you are not an administrator, not all APIs will be available.)

There are many special build steps available, like node and sh in the example. Below is a reference listing all steps available with your current set of plugins; other plugins offering Pipeline integration may be available on the update center.

Step parameters are given as key-value pairs; if there is just one mandatory parameter the name may be omitted, so

readFile 'build.properties'

is a shortcut for

readFile file: 'build.properties'

but if you specify multiple parameters they must all be named:

readFile file: 'build.properties', encoding: 'ISO-8859-1'

Many steps require complex nested configuration for a parameter. (And some nested configuration objects in turn have object-typed parameters.) There are three ways these nested objects may be specified, in decreasing order of preference:

Some configuration objects define custom symbols. These are used with a notation looking like a step call, or other function call taking a map of named parameters:
```
splitTests count(3)
```
or to spell out the mandatory parameter names:
```
splitTests parallelism: count(size: 3)
```
Compare to the equivalent using the older second syntax option:
```
splitTests parallelism: [$class: 'CountDrivenParallelism', size: 3]
```
Some Pipeline steps delegating to a single object allow the actual step name to be omitted where unambiguous, so you can write simply:
```
archiveArtifacts '**.txt'
```
rather than:
```
step([$class: 'ArtifactArchiver', artifacts: '**.txt'])
```
The nested configuration is an actual value which can be saved into variables etc.:
```
def parallelism(deterministic) {
    deterministic ? count(3) : time(15)
}
splitTests parallelism(true)
```
As maps of parameters. Default values may be omitted. (Note that [1, 2, 3] is a list in Groovy whereas [a: 1, b: 2, c: 3] is a map.)
The special map key $class is used to represent the simple or (where necessary) fully-qualified class name of the object being requested. $class may be omitted where the containing parameter allows only a single kind of nested object (or list of them):
```
checkout([$class: 'GitSCM', userRemoteConfigs: [[url: 'git://…'], extensions: [[$class: 'CleanBeforeCheckout']]])
```
In this example, GitSCM must be specified to distinguish the kind of SCM used by the delegate of checkout (the single mandatory parameter name delegate can be omitted), and CleanBeforeCheckout must be specified to distinguish the kind of GitSCMExtension used by the extensions of GitSCM—a “heterogeneous” list; but $class: 'UserRemoteConfig' may be omitted since the userRemoteConfigs of GitSCM are defined to contain only UserRemoteConfigs—it is a “homogeneous” list. (No such omission is permitted for homogeneous lists in the first syntax.)
Note that in cases where a single parameter is given, with the name omitted, and that parameter is a map, it must be enclosed in parentheses to avoid a syntactic ambiguity.
As actual Java objects:
```
import hudson.plugins.git.*
import hudson.plugins.git.extensions.impl.*
checkout(new GitSCM([new UserRemoteConfig('git://…', null, null, null)], null, false, [], null, null, [new CleanBeforeCheckout()]))
```
Besides the verbosity, such scripts cannot generally run in the Groovy sandbox without numerous signature approvals, making this mode unusable in typical secured Jenkins installations.

The Snippet Generator tool will produce the first syntax when possible, falling back to the second syntax using $class where necessary. Symbols are available in Jenkins core 2.2 and later, and some plugins.

DSL Reference

Steps

archiveArtifacts: Archive the artifacts

Archives the build artifacts (for example, distribution zip files or jar files) so that they can be downloaded later. Archived files will be accessible from the Jenkins webpage.
Normally, Jenkins keeps artifacts for a build as long as a build log itself is kept, but if you don't need old artifacts and would rather save disk space, you can do so.

Note that the Maven job type automatically archives any produced Maven artifacts. Any artifacts configured here will be archived on top of that. Automatic artifact archiving can be disabled under the advanced Maven options.

The Pipeline Snippet Generator generates this example when all arguments are set to true (some arguments by default are true):

archiveArtifacts artifacts: '**/*.txt',
                   allowEmptyArchive: true,
                   fingerprint: true,
                   onlyIfSuccessful: true

artifacts

You can use wildcards like 'module/dist/**/*.zip'. See the includes attribute of Ant fileset for the exact format -- except that "," ( comma ) is the only supported separator. The base directory is the workspace . You can only archive files that are located in your workspace.

Here are some examples of usage for pipeline:

How to archive multiple artifacts from a specific folder:
```
archiveArtifacts artifacts: 'target/*.jar'
```

How to archive multiple artifacts with different patterns:
```
archiveArtifacts artifacts: 'target/*.jar, target/*.war'
```

How to archive multiple nested artifacts:
```
archiveArtifacts artifacts: '**/*.jar'
```

Type:String

allowEmptyArchive (optional): Normally, a build fails if archiving returns zero artifacts. This option allows the archiving process to return nothing without failing the build. Instead, the build will simply throw a warning.

Type:boolean
caseSensitive (optional): Artifact archiver uses Ant org.apache.tools.ant.DirectoryScanner which by default is case sensitive. For instance, if the job produces *.hpi files, pattern "**/*.HPI" will fail to find them.

This option can be used to disable case sensitivity. When it's unchecked, pattern "**/*.HPI" will match any *.hpi files, or pattern "**/cAsEsEnSiTiVe.jar" will match a file called caseSensitive.jar.

Type:boolean
defaultExcludes (optional): Type:boolean
excludes (optional): Optionally specify the 'excludes' pattern, such as "foo/bar/**/*". Use "," to set a list of patterns. A file that matches this mask will not be archived even if it matches the mask specified in 'files to archive' section.

Type:String
fingerprint (optional): Type:boolean
followSymlinks (optional): By disabling this option all symbolic links found in the workspace will be ignored.

Type:boolean
onlyIfSuccessful (optional): Type:boolean

bat: Windows Batch Script

script: 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.

Type:String

encoding (optional): 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'

Type:String
label (optional): 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.

Type:String
returnStatus (optional): 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.

Type:boolean
returnStdout (optional): 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.

Type:boolean

build: Build a job

Trigger a new build for a given job.

Use the Pipeline Snippet Generator to generate a sample pipeline script for the build step.

job: Name of a downstream job to build. May be another Pipeline job, but more commonly a freestyle or other project. Use a simple name if the job is in the same folder as this upstream Pipeline job; otherwise can use relative paths like ../sister-folder/downstream or absolute paths like /top-level-folder/nested-folder/downstream.

Type:String

parameters (optional)

A list of parameters to pass to the downstream job. When passing secrets to downstream jobs, prefer credentials parameters over password parameters. See the documentation for details.

Array/List:

Nested choice of objects

booleanParam

name: Type:String
value: Type:boolean

credentials

name: Type:String
value: Type:String
description: Type:String

file

name

Type:String

file

Nested choice of objects

password

name

Type:String

value

org.kohsuke.stapler.NoStaplerConstructorException: There's no @DataBoundConstructor on any constructor of class hudson.util.Secret

description

Type:String

run

name: Type:String
runId: Type:String
description: Type:String

string

name: Type:String
value: Type:String

text

name: Type:String
value: Type:String

propagate (optional)

If enabled (default state), then the result of this step is that of the downstream build (e.g., success, unstable, failure, not built, or aborted). If disabled, then this step succeeds even if the downstream build is unstable, failed, etc.; use the result property of the return value as needed.

Type:boolean

quietPeriod (optional)

Optional alternate quiet period (in seconds) before building. If unset, defaults to the quiet period defined by the downstream project (or finally to the system-wide default quiet period).

Type:int

wait (optional)

If true, the pipeline will wait for the result of the build step before jumping to the next step. Defaults to true.

Type:boolean

waitForStart (optional)

If true, the pipeline will wait for the downstream build to start before jumping to the next step. Defaults to false. Overrides the value of wait.

Type:boolean

catchError: Catch error and set build result to failure

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. The behavior of the step when an exception is thrown can be configured to print a message, set a build result other than failure, change the stage result, or ignore certain kinds of exceptions that are used to interrupt the build.

This step is most useful when used in Declarative Pipeline or with the options to set the stage result or ignore build interruptions. Otherwise, consider using plain try-catch(-finally) blocks. It is also useful 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 other cases, plain try-catch(-finally) blocks may be used:

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.

buildResult (optional): If an error is caught, the overall build result will be set to this value. Note that the build result can only get worse, so you cannot change the result to SUCCESS if the current result is UNSTABLE or worse. Use SUCCESS or null to keep the build result from being set when an error is caught.

Type:String
catchInterruptions (optional): If true, certain types of exceptions that are used to interrupt the flow of execution for Pipelines will be caught and handled by the step. If false, those types of exceptions will be caught and immediately rethrown. Examples of these types of exceptions include those thrown when a build is manually aborted through the UI and those thrown by the timeout step. Defaults to true.

Type:boolean
message (optional): A message that will be logged to the console if an error is caught. If the stage result is specified, the message will also be associated with that result and may be shown in visualizations.

Type:String
stageResult (optional): If an error is caught, the stage result will be set to this value. If a message was specified, the message will be associated with this result. Use SUCCESS or null to keep the stage result from being set when an error is caught.

Type:String

checkout: Check out from version control

scm

Nested choice of objects

scmGit

The git plugin provides fundamental git operations for Jenkins projects. It can poll, fetch, checkout, and merge contents of git repositories.

The scmGit parameter of the git plugin is used with the Pipeline SCM checkout stepto checkout git repositories into Pipeline workspaces. The Pipeline Syntax Snippet Generator guides the user to select git plugin checkout options and provides online help for each of the options.



    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    Examples of the checkout step include:
    

      Checkout step with defaults
      Checkout step with https and a specific branch
      Checkout step with ssh and a private key credential
      Checkout step with https and changelog disabled
      Checkout step with git protocol and polling disabled
    
    See the argument descriptions for more details.
    

    
    The scmGit parameter of the checkout step provides access to all the Pipeline capabilities provided by the git plugin:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    

    
    NOTE: The checkout step with the scmGit parameter is the preferred SCM checkout method.
    For simpler cases that do not require all the capabilities of the git plugin, the git step can also be used.
    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    
    
    The checkout step with the scmGit parameter can be used in many cases where the git step cannot be used.
    Refer to the git plugin documentation for detailed descriptions of options available to the checkout step.
    For example, the checkout step supports:
    

      SHA-1 checkout
      Tag checkout
      Submodule checkout
      Sparse checkout
      Large file checkout (LFS)
      Reference repositories
      Branch merges
      Repository tagging
      Custom refspecs
      Timeout configuration
      Changelog calculation against a non-default reference
      Stale branch pruning
    
    

    

    Example: Checkout step with defaults
    
    Checkout from the git plugin source repository using https protocol, no credentials, and the master branch.
    
The Pipeline Snippet Generator generates this example:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    Example: Checkout step with https and a specific branch
    
    Checkout from the Jenkins source repository using https protocol, no credentials, and a specific branch (stable-2.289).
    
    The Pipeline Snippet Generator generates this example:
checkout scmGit(branches: [[name: 'stable-2.289']],
                userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/jenkins.git' ]
                ])

    

    Example: Checkout step with ssh and a private key credential
    
    Checkout from the git client plugin source repository using ssh protocol, private key credentials, and the master branch.
    The credential must be a private key credential if the remote git repository is accessed with the ssh protocol.
    The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ credentialsId: 'my-private-key-credential-id',
                           url: 'git@github.com:jenkinsci/git-client-plugin.git' ]
                     ])

    

    Example: Checkout step with https and changelog disabled
    
    Checkout from the Jenkins source repository using https protocol, no credentials, the master branch, and changelog calculation disabled.
    If changelog is false, then the changelog will not be computed for this job.
    If changelog is true or is not set, then the changelog will be computed.
    See the workflow scm step documentation for more changelog details.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'https://github.com/jenkinsci/credentials-plugin' ]
                     ])

    

    Example: Checkout step with git protocol and polling disabled
    
    Checkout from the command line git repository using git protocol, no credentials, the master branch, and no polling for changes.
    If poll is false, then the remote repository will not be polled for changes.
    If poll is true or is not set, then the remote repository will be polled for changes.
    See the workflow scm step documentation for more polling details.
    
The Pipeline Snippet Generator generates this example:
checkout poll: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'git://git.kernel.org/pub/scm/git/git.git' ]
                     ])

    

    

    Argument Descriptions

userRemoteConfigs


  Specify the repository to track. This can be a URL or a local file path.
  Note that for super-projects (repositories with submodules), only a local file
  path or a complete URL is valid.  The following are examples of valid git URLs.
  
    ssh://git@github.com/github/git.git
    git@github.com:github/git.git (short notation for ssh protocol)
    ssh://user@other.host.com/~/repos/R.git (to access the repos/R.git
    repository in the user's home directory)
    https://github.com/github/git.git
  
  

  If the repository is a super-project, the
  location from which to clone submodules is dependent on whether the repository
  is bare or non-bare (i.e. has a working directory).
  
    If the super-project is bare, the location of the submodules will be
    taken from .gitmodules.
    If the super-project is not bare, it is assumed that the
    repository has each of its submodules cloned and checked out appropriately.
    Thus, the submodules will be taken directly from a path like
    ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on
    information from .gitmodules.
  

  For a local URL/path to a super-project,
  git rev-parse --is-bare-repository
  is used to detect whether the super-project is bare or not.
  

  For a remote URL to a super-project, the ending of the URL determines whether
  a bare or non-bare repository is assumed:
  
    If the remote URL ends with .git, a non-bare repository is
    assumed.
    If the remote URL does NOT end with .git, a bare
    repository is assumed.

Array/List:

Nested object

url: Specify the URL or path of the git repository. This uses the same syntax as your git clone command.
Type:String
name: ID of the repository, such as origin, to uniquely identify this repository among other remote repositories. This is the same "name" that you use in your git remote command. If left empty, Jenkins will generate unique names for you. You normally want to specify this when you have multiple remote repositories.
Type:String
refspec: A refspec controls the remote refs to be retrieved and how they map to local refs. If left blank, it will default to the normal behaviour of git fetch, which retrieves all the branch heads as remotes/REPOSITORYNAME/BRANCHNAME. This default behaviour is OK for most cases. In other words, the default refspec is "+refs/heads/*:refs/remotes/REPOSITORYNAME/*" where REPOSITORYNAME is the value you specify in the above "name of repository" textbox. When do you want to modify this value? A good example is when you want to just retrieve one branch. For example, +refs/heads/master:refs/remotes/origin/master would only retrieve the master branch and nothing else. The plugin uses a default refspec for its initial fetch, unless the "Advanced Clone Option" is set to honor refspec. This keeps compatibility with previous behavior, and allows the job definition to decide if the refspec should be honored on initial clone. Multiple refspecs can be entered by separating them with a space character. +refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop retrieves the master branch and the develop branch and nothing else. See the refspec definition in Git user manual for more details.
Type:String
credentialsId: Credential used to check out sources.
Type:String

branches


  List of branches to build.
  Jenkins jobs are most effective when each job builds only a single branch.
  When a single job builds multiple branches, the changelog comparisons between branches often show no changes or incorrect changes.

Array/List:

Nested object

name


  Specify the branches if you'd like to track a specific branch in a repository.
  If left blank, all branches will be examined for changes and built.

  The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch
  is unambiguous.

  If your branch name has a / in it make sure to use the full reference above. When not presented
  with a full path the plugin will only use the part of the string right of the last slash.
  Meaning foo/bar will actually match bar.

  If you use a wildcard branch specifier, with a slash (e.g. release/),
  you'll need to specify the origin repository in the branch names to
  make sure changes are picked up. So e.g. origin/release/

  Possible options:
    

       <branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one. Better use refs/heads/<branchName>.

           E.g. master, feature1, ...
      
       refs/heads/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/heads/master, refs/heads/feature1/master, ...
      
       <remoteRepoName>/<branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one.

           Better use refs/heads/<branchName>.

           E.g. origin/master
      
       remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. remotes/origin/master
      
       refs/remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/remotes/origin/master
      
       <tagName>

           This does not work since the tag will not be recognized as tag.

           Use refs/tags/<tagName> instead.

           E.g. git-2.3.0
      
       refs/tags/<tagName>

           Tracks/checks out the specified tag.

           E.g. refs/tags/git-2.3.0
      
       <commitId>

           Checks out the specified commit.

           E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
      
       ${ENV_VARIABLE}

           It is also possible to use environment variables. In this case the variables are evaluated and the
           result is used as described above.

           E.g. ${TREEISH}, refs/tags/${TAGNAME}, ...
      
       <Wildcards>

           The syntax is of the form: REPOSITORYNAME/BRANCH.
           In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard,
           and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would
           match origin/branches-foo but not origin/branches/foo, while origin/branches** would
           match both origin/branches-foo and origin/branches/foo.
      
       :<regular expression>

           The syntax is of the form: :regexp.
           Regular expression syntax in branches to build will only
           build those branches whose names match the regular
           expression.

           Examples:

            
                :^(?!(origin/prefix)).*
                  
                    matches: origin or origin/master or origin/feature
                    does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
                  
                
                :origin/release-\d{8}
                  
                    matches: origin/release-20150101
                    does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
                  
                
                :^(?!origin/master$|origin/develop$).*
                  
                    matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
                    does not match: origin/master or origin/develop

Type:String

browser


  Defines the repository browser that displays changes detected by the git plugin.

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

gitTool

Name of the git tool to be used for this job. Git tool names are defined in "Global Tool Configuration".

Type:String

extensions


  
  Extensions add new behavior or modify existing plugin behavior for different uses.
  Extensions help users more precisely tune plugin behavior to meet their needs.
  
  
  Extensions include:
    

      
        Clone extensions modify the git operations that retrieve remote changes into the agent workspace.
        The extensions can adjust the amount of history retrieved, how long the retrieval is allowed to run, and other retrieval details.
      
      
        Checkout extensions modify the git operations that place files in the workspace from the git repository on the agent.
        The extensions can adjust the maximum duration of the checkout operation, the use and behavior of git submodules, the location of the workspace on the disc, and more.
      
      
        Changelog extensions adapt the source code difference calculations for different cases.
      
      
        Tagging extensions allow the plugin to apply tags in the current workspace.
      
      
        Build initiation extensions control the conditions that start a build.
        They can ignore notifications of a change or force a deeper evaluation of the commits when polling.
      
      
        Merge extensions can optionally merge changes from other branches into the current branch of the agent workspace.
        They control the source branch for the merge and the options applied to the merge.

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

doGenerateSubmoduleConfigurations (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value and always uses false as its value.

Type:boolean

submoduleCfg (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value(s) and always uses empty values.

Array/List:

Nested object

submoduleName: Removed in git plugin 4.6.0.
Type:String
branches: Removed in git plugin 4.6.0.
Array/List:
Type:String

none

changelog (optional): Enable or Disable 'Include in changelog': If 'Include in changelog' is enabled for an SCM source, then when a build occurs, the changes from that SCM source will be included in the changelog. If 'Include in changelog' is disabled, then when a build occurs, the changes from this SCM source will not be included in the changelog.
Type:boolean
poll (optional): Enable or Disable 'Include in polling' If 'Include in polling' is enabled or 'Include in changelog' is enabled, then when polling occurs, the job will be started if changes are detected from this SCM source. If 'Include in polling' is disabled and 'Include in changelog' is disabled, then when polling occurs, changes that are detected from this repository will be ignored.
Type:boolean

cleanWs: Delete workspace when build is done

cleanWhenAborted (optional)

Type:boolean

cleanWhenFailure (optional)

Type:boolean

cleanWhenNotBuilt (optional)

Type:boolean

cleanWhenSuccess (optional)

Type:boolean

cleanWhenUnstable (optional)

Type:boolean

cleanupMatrixParent (optional)

Type:boolean

deleteDirs (optional)

Type:boolean

disableDeferredWipeout (optional)

Type:boolean

externalDelete (optional)

Type:String

notFailBuild (optional)

Type:boolean

patterns (optional)

Array/List:

Nested object

pattern: Type:String
type: Values:
INCLUDE
EXCLUDE

skipWhenFailed (optional)

Type:boolean

deleteDir: Recursively delete the current directory from the workspace


    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.

dir: Change current directory


    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.

path: The relative path of the directory in the workspace to use as a new working directory.
Type:String

echo: Print Message

message: The message to write to the console output.
Type:String

emailext: Extended Email


    Step for sending email via the email-ext plugin.

subject: Type:String
body: Type:String

attachLog (optional)

Type:boolean

attachmentsPattern (optional)

Type:String

compressLog (optional)

Type:boolean

from (optional)

Type:String

mimeType (optional)

Type:String

postsendScript (optional)

Type:String

presendScript (optional)

Type:String

recipientProviders (optional)

Array/List:

Nested choice of objects

buildUser

contributor

culprits


    Sends email to the list of users who committed a change since the last non-broken build till now.
    
    This list at least always include people who made changes in this build, but if the previous build 
    was a failure it also includes the culprit list from there.

developers


    Sends email to all the people who caused a change in the change set.

brokenTestsSuspects


    Sends email to the list of users suspected of causing a unit test to begin failing.
    This list includes committers and requestors of the build where the test began to fail,
    and those for any consecutive failed builds prior to the build in which the test began to fail.
    
        
            Build Number
            1
            2
            3
            4
            5
        
        
            Requestor
            Alice
            
            
            
            Alice
        
        
            Committers
            
            Bob
Clay
            Clay
Dan
            Bob
Ed
            Ed
        
        
            foo
            Failed
            Failed
            Passed
            N/A
            Failed
        
        
            bar
            Failed
            Failed
            Passed
            N/A
            Passed
        
        
            baz
            Passed
            Failed
            Failed
            N/A
            Passed
        
        
            qux
            Passed
            Passed
            Failed
            N/A
            Passed
        
        
            new
            
            
            
            N/A
            Failed
        
        
            Suspects
            Alice (foo, bar)
            Alice (foo, bar)
Bob (baz)
Clay (baz)
            Bob (baz)
Clay (baz, qux)
Dan (qux)
            N/A
(build failed)
            Alice (foo, new)
Bob (foo, new)
Ed (foo, new)

brokenBuildSuspects

Build Number	1	2	3	4	5
Requestor	Alice				Alice
Committers		Bob Clay	Clay Dan	Bob Ed	Ed
foo	Failed	Failed	Passed	N/A	Failed
bar	Failed	Failed	Passed	N/A	Passed
baz	Passed	Failed	Failed	N/A	Passed
qux	Passed	Passed	Failed	N/A	Passed
new				N/A	Failed
Suspects	Alice (foo, bar)	Alice (foo, bar) Bob (baz) Clay (baz)	Bob (baz) Clay (baz, qux) Dan (qux)	N/A (build failed)	Alice (foo, new) Bob (foo, new) Ed (foo, new)


    Sends email to the list of users suspected of causing the build to begin failing.

recipients


    Sends email to the list of recipients defined in the "Project Recipient List."

previous


    Sends an email to the the culprits, requestor and developers of the previous build(s).

requestor


    Sends email to the user who initiated the build.

upstreamDevelopers


    Sends email to the list of users who committed changes in upstream builds that triggered this build.

replyTo (optional)

Type:String

saveOutput (optional)

Type:boolean

to (optional)

Type:String

emailextrecipients: Extended Email Recipients

recipientProviders

Array/List:

Nested choice of objects

buildUser

contributor

culprits


    Sends email to the list of users who committed a change since the last non-broken build till now.
    
    This list at least always include people who made changes in this build, but if the previous build 
    was a failure it also includes the culprit list from there.

developers


    Sends email to all the people who caused a change in the change set.

brokenTestsSuspects


    Sends email to the list of users suspected of causing a unit test to begin failing.
    This list includes committers and requestors of the build where the test began to fail,
    and those for any consecutive failed builds prior to the build in which the test began to fail.
    
        
            Build Number
            1
            2
            3
            4
            5
        
        
            Requestor
            Alice
            
            
            
            Alice
        
        
            Committers
            
            Bob
Clay
            Clay
Dan
            Bob
Ed
            Ed
        
        
            foo
            Failed
            Failed
            Passed
            N/A
            Failed
        
        
            bar
            Failed
            Failed
            Passed
            N/A
            Passed
        
        
            baz
            Passed
            Failed
            Failed
            N/A
            Passed
        
        
            qux
            Passed
            Passed
            Failed
            N/A
            Passed
        
        
            new
            
            
            
            N/A
            Failed
        
        
            Suspects
            Alice (foo, bar)
            Alice (foo, bar)
Bob (baz)
Clay (baz)
            Bob (baz)
Clay (baz, qux)
Dan (qux)
            N/A
(build failed)
            Alice (foo, new)
Bob (foo, new)
Ed (foo, new)

brokenBuildSuspects

Build Number	1	2	3	4	5
Requestor	Alice				Alice
Committers		Bob Clay	Clay Dan	Bob Ed	Ed
foo	Failed	Failed	Passed	N/A	Failed
bar	Failed	Failed	Passed	N/A	Passed
baz	Passed	Failed	Failed	N/A	Passed
qux	Passed	Passed	Failed	N/A	Passed
new				N/A	Failed
Suspects	Alice (foo, bar)	Alice (foo, bar) Bob (baz) Clay (baz)	Bob (baz) Clay (baz, qux) Dan (qux)	N/A (build failed)	Alice (foo, new) Bob (foo, new) Ed (foo, new)


    Sends email to the list of users suspected of causing the build to begin failing.

recipients


    Sends email to the list of recipients defined in the "Project Recipient List."

previous


    Sends an email to the the culprits, requestor and developers of the previous build(s).

requestor


    Sends email to the user who initiated the build.

upstreamDevelopers


    Sends email to the list of users who committed changes in upstream builds that triggered this build.

error: Error signal


    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.

message: The message that will be logged to the console when an error is caught.
Type:String

fileExists: Verify if file exists in workspace


    Checks if the given file exists on the current node.
    Returns true | false.

    This step must be run inside a node context:
# Scripted Syntax
node {
    if (fileExists('src/main/resources/index.html')) {
        echo "File src/main/resources/index.html found!"
    }
}


With the Declarative Syntax, it must be run in a stage with a defined agent (e.g. different than `agent none`):

# Declarative Syntax
stage ('Check for existence of index.html') {
    agent any # Could be a top-level directive or a stage level directive
    steps {
        script {
            if (fileExists('src/main/resources/index.html')) {
                echo "File src/main/resources/index.html found!"
            }
        }
    }
}

file


    Path to a file or a directory to verify its existence.
    
        Both absolute and relative paths are supported. When using relative path, it is relative to the current working directory (by default: the workspace).
        Both Unix and Windows path are supported using a / separator:
node('Linux') {
    if (fileExists('/usr/local/bin/jenkins.sh')) {
        sh '/usr/local/bin/jenkins.sh'
    }
}
node('Windows') {
    if (fileExists('C:/jenkins.exe')) {
        bat 'C:/jenkins.exe'
    }
}

    When using a Windows path with the backslash (\) separator, do not forget to escape it:

node('Windows') {
    if (fileExists('src\\main\\resources')) {
        echo 'Found a directory resources.'
    }
}

Type:String

findBuildScans: Find published build scans


    Inspect build log for published build scans.
    The build scans will be shown on the pipeline build page.

fingerprint: Record fingerprints of files to track usage


  Jenkins can record the 'fingerprint' of files (most often jar files) to keep
  track of where/when those files are produced and used. When you have
  inter-dependent projects on Jenkins, this allows you to quickly find out
  answers to questions like:

  
    
      I have
      foo.jar
      on my HDD but which build number of FOO did it come from?
    
    
      My BAR project depends on
      foo.jar
      from the FOO project.
    
    
      
        
          Which build of
          foo.jar
          is used in BAR #51?
        
        
          Which build of BAR contains my bug fix to
          foo.jar
          #32?
        
      
    
  

  
    To use this feature, all of the involved projects (not just the project in
    which a file is produced, but also the projects in which the file is used)
    need to use this and record fingerprints.
  

  
    See
    this document
    for more details.

targets: Can use wildcards like module/dist/**/*.zip (see the @includes of Ant fileset for the exact format). The base directory is the workspace .
Type:String

caseSensitive (optional): Fingerprinter uses Ant org.apache.tools.ant.DirectoryScanner which by default is case sensitive. For instance, if the job produces *.hpi files, pattern "**/*.HPI" will fail to find them. This option can be used to disable case sensitivity. When it's unchecked, pattern "**/*.HPI" will match any *.hpi files, or pattern "**/cAsEsEnSiTiVe.jar" will match a file called caseSensitive.jar.
Type:boolean
defaultExcludes (optional): Type:boolean
excludes (optional): Optionally specify the 'excludes' pattern, such as "foo/bar/**/*". Use "," to set a list of patterns. A file that matches this mask will not be fingerprinted even if it matches the mask specified in 'files to fingerprint' section.
Type:String

git: Git


    
    The git step performs a clone from the specified repository into a Pipeline workspace.
    
    
    Use the Pipeline Syntax Snippet Generator to generate a sample pipeline script for the git step.
    More advanced checkout operations require the checkout step with the scmGit parameter rather than the git step.
    Examples of the git step include:
    

      Git step with defaults
      Git step with https and a specific branch
      Git step with ssh and a private key credential
      Git step with https and changelog disabled
      Git step with git protocol and polling disabled
    
    See the argument descriptions for more details.
    

    
    The git step is a simplified shorthand for a subset of the more powerful checkout step with the scmGit parameter:
checkout scmGit(branches: [[name: 'main']],
    userRemoteConfigs: [[url: 'https://git-server/user/repository.git']])

    

    

    
    NOTE: The checkout step with the scmGit parameter is the preferred SCM checkout method.
    It provides significantly more functionality than the git step.
    
    Use the Pipeline Syntax Snippet Generator to generate a sample pipeline script for the checkout step.
    
    
    The checkout step with the scmGit parameter can be used in many cases where the git step cannot be used.
    Refer to the git plugin documentation for detailed descriptions of options available to the scmGit parameter of the checkout step.
    For example, the git step does not support:
    

      SHA-1 checkout
      Tag checkout
      Submodule checkout
      Sparse checkout
      Large file checkout (LFS)
      Reference repositories
      Branch merges
      Repository tagging
      Custom refspecs
      Timeout configuration
      Changelog calculation against a non-default reference
      Stale branch pruning
    
    

    

    Example: Git step with defaults
    
    Checkout from the git plugin source repository using https protocol, no credentials, and the master branch.
    
The Pipeline Syntax Snippet Generator generates this example:
git 'https://github.com/jenkinsci/git-plugin.git'

    

    Example: Git step with https and a specific branch
    
    Checkout from the Jenkins source repository using https protocol, no credentials, and a specific branch (stable-2.492).
    Note that this must be a local branch name like 'master' or 'develop'.
    
    
    Branch names that are not supported by the git step
    

       Remote branch names like 'origin/master' and 'origin/develop' are not supported as the branch argument
      SHA-1 hashes are not supported as the branch argument
      Tag names are not supported as the branch argument
    
    
    Remote branch names, SHA-1 hashes, and tag names are supported by the general purpose scmGit parameter of the checkout step.
    
    The Pipeline Syntax Snippet Generator generates this example:
git branch: 'stable-2.492',
    url: 'https://github.com/jenkinsci/jenkins.git'

    

    Example: Git step with ssh and a private key credential
    
    Checkout from the git client plugin source repository using ssh protocol, private key credentials, and the master branch.
    The credential must be a private key credential if the remote git repository is accessed with the ssh protocol.
    The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
    
The Pipeline Syntax Snippet Generator generates this example:
git credentialsId: 'my-private-key-credential-id',
    url: 'git@github.com:jenkinsci/git-client-plugin.git'

    

    Example: Git step with https and changelog disabled
    
    Checkout from the Jenkins source repository using https protocol, no credentials, the master branch, and changelog calculation disabled.
    If changelog is false, then the changelog will not be computed for this job.
    If changelog is true or is not set, then the changelog will be computed.
    See the workflow scm step documentation for more changelog details.
    
The Pipeline Syntax Snippet Generator generates this example:
git changelog: false,
    url: 'https://github.com/jenkinsci/credentials-plugin.git'

    

    Example: Git step with https protocol and polling disabled
    
    Checkout from the Jenkins platform labeler repository using https protocol, no credentials, the master branch, and no polling for changes.
    If poll is false, then the remote repository will not be polled for changes.
    If poll is true or is not set, then the remote repository will be polled for changes.
    See the workflow scm step documentation for more polling details.
    
The Pipeline Syntax Snippet Generator generates this example:
git poll: false,
    url: 'https://github.com/jenkinsci/platformlabeler-plugin.git'

    

    

    Argument Descriptions

url: URL of the repository to be checked out in the workspace. Required parameter. Repository URL's should follow the git URL guidelines. Git steps to access a secured repository should provide a Jenkins credential with the credentialsId argument rather than embedding credentials in the URL. Credentials embedded in a repository URL may be visible in console logs or in other log files.
Type:String

branch (optional): Branch to be checked out in the workspace. Default is 'master'. Note that this must be a local branch name like 'master' or 'develop'. Remote branch names like 'origin/master' and 'origin/develop' are not supported as the branch argument. Tag names are not supported as the branch argument. SHA-1 hashes are not supported as the branch argument. Remote branch names, tag names, and SHA-1 hashes are supported by the general purpose checkout step with the scmGit parameter.
Type:String
changelog (optional): Compute changelog for this job. Default is 'true'. If changelog is false, then the changelog will not be computed for this job. If changelog is true or is not set, then the changelog will be computed.
Type:boolean
credentialsId (optional): Identifier of the credential used to access the remote git repository. Default is '<empty>'. The credential must be a private key credential if the remote git repository is accessed with the ssh protocol. The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
Type:String
poll (optional): Poll remote repository for changes. Default is 'true'. If poll is false, then the remote repository will not be polled for changes. If poll is true or is not set, then the remote repository will be polled for changes.
Type:boolean

input: Wait for interactive input


    
    This step pauses Pipeline execution and allows the user to interact and control the flow of the build.
    Only a basic "proceed" or "abort" option is provided in the stage view.
    
    
    You can optionally request information back, hence the name of the step. 
    The parameter entry screen can be accessed via a link at the bottom of the build console log or
    via link in the sidebar for a build.

message

This parameter gives a prompt which will be shown to a human:

    Ready to go?
    Proceed or Abort




If you click "Proceed" the build will proceed to the next step, if you click "Abort" the build will be aborted.

Type:String

cancel (optional)

You can customize the text for the "abort" button to better match the context.



Usage: input message: 'Would you like to skip the next step?', ok: "Yes", cancel: "No, run anyway"

Which will look like:
        Would you like to skip the next step?
        Yes or No, run anyway

Type:String

id (optional)

Every input step has an unique identifier. It is used in the generated URL to proceed or abort.



    A specific identifier could be used, for example, to mechanically respond to the input from some external process/tool.

Type:String

ok (optional)

You can customize the text for the "proceed" button to better match the context.



Usage: input message: 'Do you approve?', ok: "Yes"

Which will look like:
        Do you approve?
        Yes or Abort

Type:String

parameters (optional)

Request that the submitter specify one or more parameter values when approving. If just one parameter is listed, its value will become the value of the input step. If multiple parameters are listed, the return value will be a map keyed by the parameter names. If parameters are not requested, the step returns nothing if approved.



    On the parameter entry screen you are able to enter values for parameters that are defined in this field.

Array/List:

Nested choice of objects

booleanParam

name: Type:String

defaultValue (optional): Type:boolean
description (optional): Type:String

choice

name: Type:String

description (optional)

Type:String

choices (optional)

Nested choice of objects: (not enumerable)

credentials


    Defines a credentials parameter, which you can use during a build.
    
    For security reasons, the credential is NOT directly exposed, the ID of the credential is exposed.
    
    However, the selected credential is available through variable substitution in some other parts of the configuration.
    The string value will be the ID of the credential. A supporting plugin can thus use the ID to retrieve
    the selected credential and expose it to the build in an appropriate way.

name: Type:String
defaultValue: The default credentials to use.
Type:String
credentialType: Type:String
required: When this option is selected, the credentials selection drop down will not provide the empty selection as one of the options. This will not prevent a build without a value if there are no credentials available, for example if the job does not have access to any credentials of the correct type or there is no default value and the user starting the build either does not have any credentials of the correct type in their personal credentials store or they do not have permissions on the job to use credentials from their personal store.
Type:boolean

description (optional): Type:String

file

name: Type:String

description (optional): Type:String

password


  Pass a password to your build. The password entered here is made available to
  the build in plain text as an environment variable like a string parameter
  would be. The value will be stored encrypted on the Jenkins controller,
  similar to passwords in Jenkins configuration.

name

Type:String

defaultValueAsSecret

org.kohsuke.stapler.NoStaplerConstructorException: There's no @DataBoundConstructor on any constructor of class hudson.util.Secret

description (optional): Type:String

run

name: Type:String
projectName: Type:String
filter: Values:
ALL
STABLE
SUCCESSFUL
COMPLETED

description (optional): Type:String

string

name: Type:String

defaultValue (optional): Type:String
description (optional): Type:String
trim (optional): Strip whitespace from the beginning and end of the string.
Type:boolean

text

name: Type:String

defaultValue (optional): Type:String
description (optional): Type:String
trim (optional): Strip whitespace from the beginning and end of the string.
Type:boolean

submitter (optional)


    User IDs and/or external group names of person or people permitted to respond to the input, separated by ','.
    Spaces will be trimmed. This means that "alice, bob, blah " is the same as "alice,bob,blah".

    Note: Jenkins administrators are able to respond to the input regardless of the value of this parameter. Users with Job/cancel permission may also respond with 'Abort' to the input.

Type:String

submitterParameter (optional)


    If specified, this is the name of the return value that will contain the ID of the user that approves this
    input.

    The return value will be handled in a fashion similar to the parameters value.

Type:String

isUnix: Checks if running on a Unix-like node


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

junit: Archive JUnit-formatted test results


  Jenkins understands the JUnit test report XML format (which is also used by TestNG).
  When this option is configured, Jenkins can provide useful information about test results,
  such as historical test result trends, a web UI for viewing test reports, tracking failures,
  and so on.

  
  To use this feature, first set up your build to run tests, then
  specify the path to JUnit XML files in the
  Ant glob syntax,
  such as **/build/test-reports/*.xml. Be sure not to include any non-report
  files into this pattern. You can specify multiple patterns of files separated by commas.

testResults: Type:String

allowEmptyResults (optional)


    If checked, the default behavior of failing a build on missing test result files
    or empty test results is changed to not affect the status of the build.
    Please note that this setting make it harder to spot misconfigured jobs or
    build failures where the test tool does not exit with an error code when
    not producing test report files.

Type:boolean

checksName (optional)


    If provided, and publishing checks enabled, the plugin will use this name when publishing results to corresponding
    SCM hosting platforms. If not, a default including the current stage / branch names will be used.

Type:String

healthScaleFactor (optional)


    The amplification factor to apply to test failures when computing the test result contribution to the build health
    score.
    

    The default factor is 1.0
    
        A factor of 0.0 will disable the test result contribution to build health score.
        A factor of 0.1 means that 10% of tests failing will score 99% health
        A factor of 0.5 means that 10% of tests failing will score 95% health
        A factor of 1.0 means that 10% of tests failing will score 90% health
        A factor of 2.0 means that 10% of tests failing will score 80% health
        A factor of 2.5 means that 10% of tests failing will score 75% health
        A factor of 5.0 means that 10% of tests failing will score 50% health
        A factor of 10.0 means that 10% of tests failing will score 0% health
    
    The factor is persisted with the build results, so changes will only be reflected in new builds.

Type:double

keepLongStdio (optional)


    If checked, any standard output or error from a test suite will be retained
    in the test results after the build completes. (This refers only to additional
    messages printed to console, not to a failure stack trace.) Such output is
    always kept if the test failed, but by default lengthy output from passing
    tests is truncated to save space. Check this option if you need to see every
    log message from even passing tests, but beware that Jenkins's memory consumption
    can substantially increase as a result, even if you never look at the test results!

Type:boolean

keepProperties (optional)

Type:boolean

keepTestNames (optional)

Type:boolean

skipMarkingBuildUnstable (optional)


    If this option is unchecked, then the plugin will mark the build as unstable when it finds at least 1 test failure.
    If this option is checked, then the build will still be successful even if there are test failures reported.
    In any case, the corresponding pipeline node (and stage) will be marked as unstable in case of test failure.

Type:boolean

skipOldReports (optional)

Type:boolean

skipPublishingChecks (optional)


    If this option is unchecked, then the plugin automatically publishes the test results to corresponding SCM hosting platforms.
    For example, if you are using this feature for a GitHub organization project, the warnings will be published to
    GitHub through the Checks API. If this operation slows down your build, or you don't want to publish the warnings to
    SCM platforms, you can use this option to deactivate this feature.

Type:boolean

stdioRetention (optional)

Type:String

testDataPublishers (optional)

Array/List:

Nested choice of objects

library: Load a library on the fly


    
        Load a library dynamically rather than using @Library syntax.
        You may use global variables defined in the library thereafter:
    
    
library 'mylib@master'
usefulFunction()

    
        You may also load classes defined in the library by selecting their fully-qualified names
        like properties on the return value of this step, then call static methods
        or call constructors as if they were a method named new:
    
    
def utils = library('mylib').com.mycorp.jenkins.Utils.new(this)
utils.handyStuff()

identifier: A library name to load. Should normally match that of a predefined library. You can append a version after @. You may instead define a library inline here.
Type:String

changelog (optional)


    Whether to include any changes in the library
    in the recent changes of jobs using the library.
    Defaults to including the changes.

Type:boolean

retriever (optional)

Nested choice of objects

legacySCM

scm

Nested choice of objects

scmGit


  
  The git plugin provides fundamental git operations for Jenkins projects.
  It can poll, fetch, checkout, and merge contents of git repositories.
  

  
  The scmGit parameter of the git plugin is used with the Pipeline SCM checkout step to checkout git repositories into Pipeline workspaces.
  The Pipeline Syntax Snippet Generator guides the user to select git plugin checkout options and provides online help for each of the options.
  


    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    Examples of the checkout step include:
    

      Checkout step with defaults
      Checkout step with https and a specific branch
      Checkout step with ssh and a private key credential
      Checkout step with https and changelog disabled
      Checkout step with git protocol and polling disabled
    
    See the argument descriptions for more details.
    

    
    The scmGit parameter of the checkout step provides access to all the Pipeline capabilities provided by the git plugin:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    

    
    NOTE: The checkout step with the scmGit parameter is the preferred SCM checkout method.
    For simpler cases that do not require all the capabilities of the git plugin, the git step can also be used.
    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    
    
    The checkout step with the scmGit parameter can be used in many cases where the git step cannot be used.
    Refer to the git plugin documentation for detailed descriptions of options available to the checkout step.
    For example, the checkout step supports:
    

      SHA-1 checkout
      Tag checkout
      Submodule checkout
      Sparse checkout
      Large file checkout (LFS)
      Reference repositories
      Branch merges
      Repository tagging
      Custom refspecs
      Timeout configuration
      Changelog calculation against a non-default reference
      Stale branch pruning
    
    

    

    Example: Checkout step with defaults
    
    Checkout from the git plugin source repository using https protocol, no credentials, and the master branch.
    
The Pipeline Snippet Generator generates this example:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    Example: Checkout step with https and a specific branch
    
    Checkout from the Jenkins source repository using https protocol, no credentials, and a specific branch (stable-2.289).
    
    The Pipeline Snippet Generator generates this example:
checkout scmGit(branches: [[name: 'stable-2.289']],
                userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/jenkins.git' ]
                ])

    

    Example: Checkout step with ssh and a private key credential
    
    Checkout from the git client plugin source repository using ssh protocol, private key credentials, and the master branch.
    The credential must be a private key credential if the remote git repository is accessed with the ssh protocol.
    The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ credentialsId: 'my-private-key-credential-id',
                           url: 'git@github.com:jenkinsci/git-client-plugin.git' ]
                     ])

    

    Example: Checkout step with https and changelog disabled
    
    Checkout from the Jenkins source repository using https protocol, no credentials, the master branch, and changelog calculation disabled.
    If changelog is false, then the changelog will not be computed for this job.
    If changelog is true or is not set, then the changelog will be computed.
    See the workflow scm step documentation for more changelog details.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'https://github.com/jenkinsci/credentials-plugin' ]
                     ])

    

    Example: Checkout step with git protocol and polling disabled
    
    Checkout from the command line git repository using git protocol, no credentials, the master branch, and no polling for changes.
    If poll is false, then the remote repository will not be polled for changes.
    If poll is true or is not set, then the remote repository will be polled for changes.
    See the workflow scm step documentation for more polling details.
    
The Pipeline Snippet Generator generates this example:
checkout poll: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'git://git.kernel.org/pub/scm/git/git.git' ]
                     ])

    

    

    Argument Descriptions

userRemoteConfigs


  Specify the repository to track. This can be a URL or a local file path.
  Note that for super-projects (repositories with submodules), only a local file
  path or a complete URL is valid.  The following are examples of valid git URLs.
  
    ssh://git@github.com/github/git.git
    git@github.com:github/git.git (short notation for ssh protocol)
    ssh://user@other.host.com/~/repos/R.git (to access the repos/R.git
    repository in the user's home directory)
    https://github.com/github/git.git
  
  

  If the repository is a super-project, the
  location from which to clone submodules is dependent on whether the repository
  is bare or non-bare (i.e. has a working directory).
  
    If the super-project is bare, the location of the submodules will be
    taken from .gitmodules.
    If the super-project is not bare, it is assumed that the
    repository has each of its submodules cloned and checked out appropriately.
    Thus, the submodules will be taken directly from a path like
    ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on
    information from .gitmodules.
  

  For a local URL/path to a super-project,
  git rev-parse --is-bare-repository
  is used to detect whether the super-project is bare or not.
  

  For a remote URL to a super-project, the ending of the URL determines whether
  a bare or non-bare repository is assumed:
  
    If the remote URL ends with .git, a non-bare repository is
    assumed.
    If the remote URL does NOT end with .git, a bare
    repository is assumed.

Array/List:

Nested object

url: Specify the URL or path of the git repository. This uses the same syntax as your git clone command.
Type:String
name: ID of the repository, such as origin, to uniquely identify this repository among other remote repositories. This is the same "name" that you use in your git remote command. If left empty, Jenkins will generate unique names for you. You normally want to specify this when you have multiple remote repositories.
Type:String
refspec: A refspec controls the remote refs to be retrieved and how they map to local refs. If left blank, it will default to the normal behaviour of git fetch, which retrieves all the branch heads as remotes/REPOSITORYNAME/BRANCHNAME. This default behaviour is OK for most cases. In other words, the default refspec is "+refs/heads/*:refs/remotes/REPOSITORYNAME/*" where REPOSITORYNAME is the value you specify in the above "name of repository" textbox. When do you want to modify this value? A good example is when you want to just retrieve one branch. For example, +refs/heads/master:refs/remotes/origin/master would only retrieve the master branch and nothing else. The plugin uses a default refspec for its initial fetch, unless the "Advanced Clone Option" is set to honor refspec. This keeps compatibility with previous behavior, and allows the job definition to decide if the refspec should be honored on initial clone. Multiple refspecs can be entered by separating them with a space character. +refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop retrieves the master branch and the develop branch and nothing else. See the refspec definition in Git user manual for more details.
Type:String
credentialsId: Credential used to check out sources.
Type:String

branches


  List of branches to build.
  Jenkins jobs are most effective when each job builds only a single branch.
  When a single job builds multiple branches, the changelog comparisons between branches often show no changes or incorrect changes.

Array/List:

Nested object

name


  Specify the branches if you'd like to track a specific branch in a repository.
  If left blank, all branches will be examined for changes and built.

  The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch
  is unambiguous.

  If your branch name has a / in it make sure to use the full reference above. When not presented
  with a full path the plugin will only use the part of the string right of the last slash.
  Meaning foo/bar will actually match bar.

  If you use a wildcard branch specifier, with a slash (e.g. release/),
  you'll need to specify the origin repository in the branch names to
  make sure changes are picked up. So e.g. origin/release/

  Possible options:
    

       <branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one. Better use refs/heads/<branchName>.

           E.g. master, feature1, ...
      
       refs/heads/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/heads/master, refs/heads/feature1/master, ...
      
       <remoteRepoName>/<branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one.

           Better use refs/heads/<branchName>.

           E.g. origin/master
      
       remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. remotes/origin/master
      
       refs/remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/remotes/origin/master
      
       <tagName>

           This does not work since the tag will not be recognized as tag.

           Use refs/tags/<tagName> instead.

           E.g. git-2.3.0
      
       refs/tags/<tagName>

           Tracks/checks out the specified tag.

           E.g. refs/tags/git-2.3.0
      
       <commitId>

           Checks out the specified commit.

           E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
      
       ${ENV_VARIABLE}

           It is also possible to use environment variables. In this case the variables are evaluated and the
           result is used as described above.

           E.g. ${TREEISH}, refs/tags/${TAGNAME}, ...
      
       <Wildcards>

           The syntax is of the form: REPOSITORYNAME/BRANCH.
           In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard,
           and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would
           match origin/branches-foo but not origin/branches/foo, while origin/branches** would
           match both origin/branches-foo and origin/branches/foo.
      
       :<regular expression>

           The syntax is of the form: :regexp.
           Regular expression syntax in branches to build will only
           build those branches whose names match the regular
           expression.

           Examples:

            
                :^(?!(origin/prefix)).*
                  
                    matches: origin or origin/master or origin/feature
                    does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
                  
                
                :origin/release-\d{8}
                  
                    matches: origin/release-20150101
                    does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
                  
                
                :^(?!origin/master$|origin/develop$).*
                  
                    matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
                    does not match: origin/master or origin/develop

Type:String

browser


  Defines the repository browser that displays changes detected by the git plugin.

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

gitTool

Name of the git tool to be used for this job. Git tool names are defined in "Global Tool Configuration".

Type:String

extensions


  
  Extensions add new behavior or modify existing plugin behavior for different uses.
  Extensions help users more precisely tune plugin behavior to meet their needs.
  
  
  Extensions include:
    

      
        Clone extensions modify the git operations that retrieve remote changes into the agent workspace.
        The extensions can adjust the amount of history retrieved, how long the retrieval is allowed to run, and other retrieval details.
      
      
        Checkout extensions modify the git operations that place files in the workspace from the git repository on the agent.
        The extensions can adjust the maximum duration of the checkout operation, the use and behavior of git submodules, the location of the workspace on the disc, and more.
      
      
        Changelog extensions adapt the source code difference calculations for different cases.
      
      
        Tagging extensions allow the plugin to apply tags in the current workspace.
      
      
        Build initiation extensions control the conditions that start a build.
        They can ignore notifications of a change or force a deeper evaluation of the commits when polling.
      
      
        Merge extensions can optionally merge changes from other branches into the current branch of the agent workspace.
        They control the source branch for the merge and the options applied to the merge.

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

doGenerateSubmoduleConfigurations (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value and always uses false as its value.

Type:boolean

submoduleCfg (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value(s) and always uses empty values.

Array/List:

Nested object

submoduleName: Removed in git plugin 4.6.0.
Type:String
branches: Removed in git plugin 4.6.0.
Array/List:
Type:String

none

clone (optional): If checked, every build performs a fresh clone of the SCM rather than locking and updating a common copy. No changelog will be computed. For Git, you are advised to add Advanced clone behaviors and then check Shallow clone and Honor refspec on initial clone and uncheck Fetch tags to make the clone much faster. You may still enable Cache fetched versions on controller for quick retrieval if you prefer.
Type:boolean
libraryPath (optional): A relative path from the root of the SCM to the root of the library. Leave this field blank if the root of the library is the root of the SCM. Note that ".." is not permitted as a path component to avoid security issues.
Type:String

modernSCM

scm

Nested choice of objects

github

repoOwner


    Specify the name of the GitHub Organization or GitHub User Account.

Type:String

repository


    The repository to scan.

Type:String

repositoryUrl


    Specify the HTTPS URL of the GitHub Organization / User Account and repository.
    
        GitHub examples:
        

            https://github.com/jenkinsci/github-branch-source-plugin
            https://github.com/jenkinsci/github-branch-source-plugin.git
        
    
    
        GitHub Enterprise examples:
        

            https://myccompany.github.com/jenkinsci/github-branch-source-plugin
            https://myccompany.github.com/jenkinsci/github-branch-source-plugin.git

Type:String

configuredByUrl

Type:boolean

apiUri (optional)


    The server to connect to. The list of servers is configured in the Manage Jenkins » Configure
    System » GitHub Enterprise Servers screen.

Type:String

buildForkPRHead (optional)

Type:boolean

buildForkPRMerge (optional)

Type:boolean

buildOriginBranch (optional)

Type:boolean

buildOriginBranchWithPR (optional)

Type:boolean

buildOriginPRHead (optional)

Type:boolean

buildOriginPRMerge (optional)

Type:boolean

credentialsId (optional)


    
        Credentials used to scan branches and pull requests,
        check out sources and mark commit statuses.
    
    
        Note that only "username with password" credentials are supported.
        Existing credentials of other kinds will be filtered out. This is because Jenkins
        uses the GitHub API, which does not support other ways of authentication.
    
    
        If none is given, only the public repositories will be scanned, and commit status
        will not be set on GitHub.
    
    
        If your organization contains private repositories, then you need to specify
        a credential from a user who has access to those repositories. This is done
        by creating a "username with password" credential where the password is
        GitHub personal access tokens.
        The necessary scope is "repo".

Type:String

excludes (optional)

Type:String

id (optional)

Type:String

includes (optional)

Type:String

traits (optional)


    The behaviours control what is discovered from the GitHub repository. The behaviours are grouped into a number
    of categories:
    
        Within repository
        These behaviours determine what gets discovered. If you do not configure at least one discovery
            behaviour then nothing will be found!
        General
        These behaviours affect the configuration of each discovered branch / pull request.

Array/List:

Nested choice of objects

authorInChangelog

checkoutOption

extension

: timeout
Specify a timeout (in minutes) for checkout.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

cleanAfterCheckout

extension

: Clean up the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cleanBeforeCheckout

extension

: Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cloneOption

extension

: shallow
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
noTags
Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.

Type:boolean
reference
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

Type:String
timeout
Specify a timeout (in minutes) for clone and fetch operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
honorRefspec (optional)
Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.

Type:boolean

discoverOtherRefs


    Discovers other specified refs on the repository.

ref: The pattern under /refs on the remote repository to discover, can contain a wildcard. Example: test/*/merged
Type:String

nameMapping (optional): Mapping for how the ref can be named in for example the @Library. Example: test-@{1} Where @{1} replaces the first wildcard in the ref when discovered.
By default it will be "namespace_before_wildcard-@{1}". E.g. if ref is "test/*/merged" the default mapping would be "test-@{1}".
Type:String

firstBuildChangelog

extension

: First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes. By default, no changelog is generated for the first build because the first build has no predecessor build for comparison. When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional)
Type:boolean

gitHubForkDiscovery


    Discovers pull requests where the origin repository is a fork of the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

trust


    
        One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit
        some changes to their fork and then create a pull request against the original repository with their changes.
        There are some files stored in source control that are important. For example, a Jenkinsfile
        may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests.
        In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove
        the protections, you can define the trust policy for pull requests from forks.
    
    
        Other plugins can extend the available trust policies. The default policies are:
    
    
        Nobody
        
            Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a
            trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the
            target branch on the origin repository and not from the pull request branch on the fork repository.
        
        Collaborators
        
            Pull requests from collaborators
            to the origin repository will be treated as trusted, all other pull requests from fork repositories
            will be treated as untrusted.
            Note that if credentials used by Jenkins for scanning the repository does not have permission to
            query the list of collaborators to the origin repository then only the origin account will be treated
            as trusted - i.e. this will fall back to Nobody.
            NOTE: all collaborators are trusted, even if they are only members of a team with read permission.
        
        Everyone
        
            All pull requests from forks will be treated as trusted. NOTE: this option can be dangerous
            if used on a public repository hosted on GitHub.
        
        From users with Admin or Write permission
        
            Pull requests forks will be treated as trusted if and only if the fork owner has either Admin or Write
            permissions on the origin repository.
            This is the recommended policy.
            Note that this strategy requires the
            Review
            a user's permission level API, as a result on GitHub Enterprise Server versions before 2.12 this
            is the same as trusting Nobody.

Nested choice of objects

gitHubTrustContributors

gitHubTrustEveryone

gitHubTrustNobody

gitHubTrustPermissions

browser

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

lfs

gitTool

gitTool: Type:String

gitHubIgnoreDraftPullRequestFilter

ignoreOnPush

localBranch

multiBranchProjectDisplayNaming


    Some branch source plugins provide additional information about discovered branches like a title or subject of merge or change requests.

    With this trait, that additional information can be used for the job display names.

    Note: Job display name changes do not trigger builds.

displayNamingStrategy


  The different strategies:
  
    
      
        Job display name with fallback to name:
        

        Uses the branch source plugin's display name for the PR instead of the raw name
        

        Value for configuration-as-code: OBJECT_DISPLAY_NAME
      
    
    
      
        Name and, if available, display name:
        

        Joins the raw name and the branch source plugin's display name
        

        Value for configuration-as-code: RAW_AND_OBJECT_DISPLAY_NAME
      
    
    
      
        Simple name:
        

        Just the raw name
        

        Value for configuration-as-code: RAW

Values:

OBJECT_DISPLAY_NAME

RAW_AND_OBJECT_DISPLAY_NAME

RAW

gitHubPullRequestDiscovery


    Discovers pull requests where the origin repository is the same as the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

pruneStaleBranch

pruneStaleTag

refSpecs

templates

Array/List:

Nested object

value: A ref spec to fetch. Any occurrences of @{remote} will be replaced by the remote name (which defaults to origin) before use.
Type:String

headRegexFilter

regex: A Java regular expression to restrict the names. Names that do not match the supplied regular expression will be ignored. NOTE: this filter will be applied to all branch like things, including change requests
Type:String

remoteName

remoteName: Type:String

gitHubSshCheckout


    By default the discovered branches / pull requests will all use the same username / password credentials
    that were used for discovery when checking out sources. This means that the checkout will be using the
    https:// protocol for the Git repository.
    
        This behaviour allows you to select the SSH private key to be used for checking out sources, which will
        consequently force the checkout to use the ssh:// protocol.

credentialsId: Credentials used to check out sources. Must be a SSH key based credential.
Type:String

sparseCheckoutPaths

extension

: Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths
Array/List:
Nested object
path
Type:String

submoduleOption

extension

: depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
disableSubmodules (optional)
By disabling support for submodules you can still keep using basic git plugin functionality and just have Jenkins to ignore submodules completely as if they didn't exist.

Type:boolean
parentCredentials (optional)
Use credentials from the default remote of the parent project.

Type:boolean
recursiveSubmodules (optional)
Retrieve all submodules recursively (uses '--recursive' option which requires git>=1.6.5)

Type:boolean
reference (optional)
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

git init --bare git remote add SubProject1 https://gitrepo.com/subproject1 git remote add SubProject2 https://gitrepo.com/subproject2 git fetch --all

Type:String
shallow (optional)
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
threads (optional)
Specify the number of threads that will be used to update submodules.
If unspecified, the command line git default thread count is used.

Type:int
timeout (optional)
Specify a timeout (in minutes) for submodules operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
trackingSubmodules (optional)
Retrieve the tip of the configured branch in .gitmodules (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

userIdentity

extension

Nested object

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

headWildcardFilter

includes: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release* NOTE: this filter will be applied to all branch like things, including change requests
Type:String
excludes: Space-separated list of name patterns to ignore even if matched by the includes list. For example: release alpha-* beta-* NOTE: this filter will be applied to all branch like things, including change requests
Type:String

$class: 'WipeWorkspaceTrait'

gitBranchDiscovery


    Discovers branches on the repository.

gitTagDiscovery


    Discovers tags on the repository.

gitHubBranchDiscovery


    Discovers branches on the repository.

strategyId


    Determines which branches are discovered.
    
        Exclude branches that are also filed as PRs
        
            If you are discovering origin pull requests, you may not want to also build the source branches
            for those pull requests.
        
        Only branches that are also filed as PRs
        
            Similar to discovering origin pull requests, but discovers the branch rather than the pull request. 
            This means env.GIT_BRANCH will be set to the branch name rather than PR-#.
            Also, status notifications for these builds will only be applied to the commit and not to the pull request.
        
        All branches
        
            Ignores whether the branch is also filed as a pull request and instead discovers all branches on the
            origin repository.

Type:int

gitHubTagDiscovery


    Discovers tags on the repository.

gitSource

remote: Specify the URL of this remote repository. This uses the same syntax as your git clone command.
Type:String

browser (optional)

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

credentialsId (optional)




    Credentials used to scan branches and check out sources.

Type:String

extensions (optional)

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

gitTool (optional)

Type:String

id (optional)

Type:String

traits (optional)

Array/List:

Nested choice of objects

authorInChangelog

checkoutOption

extension

: timeout
Specify a timeout (in minutes) for checkout.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

cleanAfterCheckout

extension

: Clean up the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cleanBeforeCheckout

extension

: Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cloneOption

extension

: shallow
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
noTags
Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.

Type:boolean
reference
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

Type:String
timeout
Specify a timeout (in minutes) for clone and fetch operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
honorRefspec (optional)
Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.

Type:boolean

discoverOtherRefs


    Discovers other specified refs on the repository.

ref: The pattern under /refs on the remote repository to discover, can contain a wildcard. Example: test/*/merged
Type:String

nameMapping (optional): Mapping for how the ref can be named in for example the @Library. Example: test-@{1} Where @{1} replaces the first wildcard in the ref when discovered.
By default it will be "namespace_before_wildcard-@{1}". E.g. if ref is "test/*/merged" the default mapping would be "test-@{1}".
Type:String

firstBuildChangelog

extension

: First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes. By default, no changelog is generated for the first build because the first build has no predecessor build for comparison. When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional)
Type:boolean

gitHubForkDiscovery


    Discovers pull requests where the origin repository is a fork of the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

trust


    
        One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit
        some changes to their fork and then create a pull request against the original repository with their changes.
        There are some files stored in source control that are important. For example, a Jenkinsfile
        may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests.
        In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove
        the protections, you can define the trust policy for pull requests from forks.
    
    
        Other plugins can extend the available trust policies. The default policies are:
    
    
        Nobody
        
            Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a
            trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the
            target branch on the origin repository and not from the pull request branch on the fork repository.
        
        Collaborators
        
            Pull requests from collaborators
            to the origin repository will be treated as trusted, all other pull requests from fork repositories
            will be treated as untrusted.
            Note that if credentials used by Jenkins for scanning the repository does not have permission to
            query the list of collaborators to the origin repository then only the origin account will be treated
            as trusted - i.e. this will fall back to Nobody.
            NOTE: all collaborators are trusted, even if they are only members of a team with read permission.
        
        Everyone
        
            All pull requests from forks will be treated as trusted. NOTE: this option can be dangerous
            if used on a public repository hosted on GitHub.
        
        From users with Admin or Write permission
        
            Pull requests forks will be treated as trusted if and only if the fork owner has either Admin or Write
            permissions on the origin repository.
            This is the recommended policy.
            Note that this strategy requires the
            Review
            a user's permission level API, as a result on GitHub Enterprise Server versions before 2.12 this
            is the same as trusting Nobody.

Nested choice of objects

gitHubTrustContributors

gitHubTrustEveryone

gitHubTrustNobody

gitHubTrustPermissions

browser

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

lfs

gitTool

gitTool: Type:String

gitHubIgnoreDraftPullRequestFilter

ignoreOnPush

localBranch

multiBranchProjectDisplayNaming


    Some branch source plugins provide additional information about discovered branches like a title or subject of merge or change requests.

    With this trait, that additional information can be used for the job display names.

    Note: Job display name changes do not trigger builds.

displayNamingStrategy


  The different strategies:
  
    
      
        Job display name with fallback to name:
        

        Uses the branch source plugin's display name for the PR instead of the raw name
        

        Value for configuration-as-code: OBJECT_DISPLAY_NAME
      
    
    
      
        Name and, if available, display name:
        

        Joins the raw name and the branch source plugin's display name
        

        Value for configuration-as-code: RAW_AND_OBJECT_DISPLAY_NAME
      
    
    
      
        Simple name:
        

        Just the raw name
        

        Value for configuration-as-code: RAW

Values:

OBJECT_DISPLAY_NAME

RAW_AND_OBJECT_DISPLAY_NAME

RAW

gitHubPullRequestDiscovery


    Discovers pull requests where the origin repository is the same as the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

pruneStaleBranch

pruneStaleTag

refSpecs

templates

Array/List:

Nested object

value: A ref spec to fetch. Any occurrences of @{remote} will be replaced by the remote name (which defaults to origin) before use.
Type:String

headRegexFilter

regex: A Java regular expression to restrict the names. Names that do not match the supplied regular expression will be ignored. NOTE: this filter will be applied to all branch like things, including change requests
Type:String

remoteName

remoteName: Type:String

gitHubSshCheckout


    By default the discovered branches / pull requests will all use the same username / password credentials
    that were used for discovery when checking out sources. This means that the checkout will be using the
    https:// protocol for the Git repository.
    
        This behaviour allows you to select the SSH private key to be used for checking out sources, which will
        consequently force the checkout to use the ssh:// protocol.

credentialsId: Credentials used to check out sources. Must be a SSH key based credential.
Type:String

sparseCheckoutPaths

extension

: Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths
Array/List:
Nested object
path
Type:String

submoduleOption

extension

: depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
disableSubmodules (optional)
By disabling support for submodules you can still keep using basic git plugin functionality and just have Jenkins to ignore submodules completely as if they didn't exist.

Type:boolean
parentCredentials (optional)
Use credentials from the default remote of the parent project.

Type:boolean
recursiveSubmodules (optional)
Retrieve all submodules recursively (uses '--recursive' option which requires git>=1.6.5)

Type:boolean
reference (optional)
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

git init --bare git remote add SubProject1 https://gitrepo.com/subproject1 git remote add SubProject2 https://gitrepo.com/subproject2 git fetch --all

Type:String
shallow (optional)
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
threads (optional)
Specify the number of threads that will be used to update submodules.
If unspecified, the command line git default thread count is used.

Type:int
timeout (optional)
Specify a timeout (in minutes) for submodules operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
trackingSubmodules (optional)
Retrieve the tip of the configured branch in .gitmodules (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

userIdentity

extension

Nested object

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

headWildcardFilter

includes: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release* NOTE: this filter will be applied to all branch like things, including change requests
Type:String
excludes: Space-separated list of name patterns to ignore even if matched by the includes list. For example: release alpha-* beta-* NOTE: this filter will be applied to all branch like things, including change requests
Type:String

$class: 'WipeWorkspaceTrait'

gitBranchDiscovery


    Discovers branches on the repository.

gitTagDiscovery


    Discovers tags on the repository.

gitHubBranchDiscovery


    Discovers branches on the repository.

strategyId


    Determines which branches are discovered.
    
        Exclude branches that are also filed as PRs
        
            If you are discovering origin pull requests, you may not want to also build the source branches
            for those pull requests.
        
        Only branches that are also filed as PRs
        
            Similar to discovering origin pull requests, but discovers the branch rather than the pull request. 
            This means env.GIT_BRANCH will be set to the branch name rather than PR-#.
            Also, status notifications for these builds will only be applied to the commit and not to the pull request.
        
        All branches
        
            Ignores whether the branch is also filed as a pull request and instead discovers all branches on the
            origin repository.

Type:int

gitHubTagDiscovery


    Discovers tags on the repository.

fromScm

name


    The name of the SCM head/trunk/branch/tag that this source provides.

Type:String

scm

Nested choice of objects

scmGit


  
  The git plugin provides fundamental git operations for Jenkins projects.
  It can poll, fetch, checkout, and merge contents of git repositories.
  

  
  The scmGit parameter of the git plugin is used with the Pipeline SCM checkout step to checkout git repositories into Pipeline workspaces.
  The Pipeline Syntax Snippet Generator guides the user to select git plugin checkout options and provides online help for each of the options.
  


    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    Examples of the checkout step include:
    

      Checkout step with defaults
      Checkout step with https and a specific branch
      Checkout step with ssh and a private key credential
      Checkout step with https and changelog disabled
      Checkout step with git protocol and polling disabled
    
    See the argument descriptions for more details.
    

    
    The scmGit parameter of the checkout step provides access to all the Pipeline capabilities provided by the git plugin:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    

    
    NOTE: The checkout step with the scmGit parameter is the preferred SCM checkout method.
    For simpler cases that do not require all the capabilities of the git plugin, the git step can also be used.
    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    
    
    The checkout step with the scmGit parameter can be used in many cases where the git step cannot be used.
    Refer to the git plugin documentation for detailed descriptions of options available to the checkout step.
    For example, the checkout step supports:
    

      SHA-1 checkout
      Tag checkout
      Submodule checkout
      Sparse checkout
      Large file checkout (LFS)
      Reference repositories
      Branch merges
      Repository tagging
      Custom refspecs
      Timeout configuration
      Changelog calculation against a non-default reference
      Stale branch pruning
    
    

    

    Example: Checkout step with defaults
    
    Checkout from the git plugin source repository using https protocol, no credentials, and the master branch.
    
The Pipeline Snippet Generator generates this example:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    Example: Checkout step with https and a specific branch
    
    Checkout from the Jenkins source repository using https protocol, no credentials, and a specific branch (stable-2.289).
    
    The Pipeline Snippet Generator generates this example:
checkout scmGit(branches: [[name: 'stable-2.289']],
                userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/jenkins.git' ]
                ])

    

    Example: Checkout step with ssh and a private key credential
    
    Checkout from the git client plugin source repository using ssh protocol, private key credentials, and the master branch.
    The credential must be a private key credential if the remote git repository is accessed with the ssh protocol.
    The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ credentialsId: 'my-private-key-credential-id',
                           url: 'git@github.com:jenkinsci/git-client-plugin.git' ]
                     ])

    

    Example: Checkout step with https and changelog disabled
    
    Checkout from the Jenkins source repository using https protocol, no credentials, the master branch, and changelog calculation disabled.
    If changelog is false, then the changelog will not be computed for this job.
    If changelog is true or is not set, then the changelog will be computed.
    See the workflow scm step documentation for more changelog details.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'https://github.com/jenkinsci/credentials-plugin' ]
                     ])

    

    Example: Checkout step with git protocol and polling disabled
    
    Checkout from the command line git repository using git protocol, no credentials, the master branch, and no polling for changes.
    If poll is false, then the remote repository will not be polled for changes.
    If poll is true or is not set, then the remote repository will be polled for changes.
    See the workflow scm step documentation for more polling details.
    
The Pipeline Snippet Generator generates this example:
checkout poll: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'git://git.kernel.org/pub/scm/git/git.git' ]
                     ])

    

    

    Argument Descriptions

userRemoteConfigs


  Specify the repository to track. This can be a URL or a local file path.
  Note that for super-projects (repositories with submodules), only a local file
  path or a complete URL is valid.  The following are examples of valid git URLs.
  
    ssh://git@github.com/github/git.git
    git@github.com:github/git.git (short notation for ssh protocol)
    ssh://user@other.host.com/~/repos/R.git (to access the repos/R.git
    repository in the user's home directory)
    https://github.com/github/git.git
  
  

  If the repository is a super-project, the
  location from which to clone submodules is dependent on whether the repository
  is bare or non-bare (i.e. has a working directory).
  
    If the super-project is bare, the location of the submodules will be
    taken from .gitmodules.
    If the super-project is not bare, it is assumed that the
    repository has each of its submodules cloned and checked out appropriately.
    Thus, the submodules will be taken directly from a path like
    ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on
    information from .gitmodules.
  

  For a local URL/path to a super-project,
  git rev-parse --is-bare-repository
  is used to detect whether the super-project is bare or not.
  

  For a remote URL to a super-project, the ending of the URL determines whether
  a bare or non-bare repository is assumed:
  
    If the remote URL ends with .git, a non-bare repository is
    assumed.
    If the remote URL does NOT end with .git, a bare
    repository is assumed.

Array/List:

Nested object

url: Specify the URL or path of the git repository. This uses the same syntax as your git clone command.
Type:String
name: ID of the repository, such as origin, to uniquely identify this repository among other remote repositories. This is the same "name" that you use in your git remote command. If left empty, Jenkins will generate unique names for you. You normally want to specify this when you have multiple remote repositories.
Type:String
refspec: A refspec controls the remote refs to be retrieved and how they map to local refs. If left blank, it will default to the normal behaviour of git fetch, which retrieves all the branch heads as remotes/REPOSITORYNAME/BRANCHNAME. This default behaviour is OK for most cases. In other words, the default refspec is "+refs/heads/*:refs/remotes/REPOSITORYNAME/*" where REPOSITORYNAME is the value you specify in the above "name of repository" textbox. When do you want to modify this value? A good example is when you want to just retrieve one branch. For example, +refs/heads/master:refs/remotes/origin/master would only retrieve the master branch and nothing else. The plugin uses a default refspec for its initial fetch, unless the "Advanced Clone Option" is set to honor refspec. This keeps compatibility with previous behavior, and allows the job definition to decide if the refspec should be honored on initial clone. Multiple refspecs can be entered by separating them with a space character. +refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop retrieves the master branch and the develop branch and nothing else. See the refspec definition in Git user manual for more details.
Type:String
credentialsId: Credential used to check out sources.
Type:String

branches


  List of branches to build.
  Jenkins jobs are most effective when each job builds only a single branch.
  When a single job builds multiple branches, the changelog comparisons between branches often show no changes or incorrect changes.

Array/List:

Nested object

name


  Specify the branches if you'd like to track a specific branch in a repository.
  If left blank, all branches will be examined for changes and built.

  The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch
  is unambiguous.

  If your branch name has a / in it make sure to use the full reference above. When not presented
  with a full path the plugin will only use the part of the string right of the last slash.
  Meaning foo/bar will actually match bar.

  If you use a wildcard branch specifier, with a slash (e.g. release/),
  you'll need to specify the origin repository in the branch names to
  make sure changes are picked up. So e.g. origin/release/

  Possible options:
    

       <branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one. Better use refs/heads/<branchName>.

           E.g. master, feature1, ...
      
       refs/heads/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/heads/master, refs/heads/feature1/master, ...
      
       <remoteRepoName>/<branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one.

           Better use refs/heads/<branchName>.

           E.g. origin/master
      
       remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. remotes/origin/master
      
       refs/remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/remotes/origin/master
      
       <tagName>

           This does not work since the tag will not be recognized as tag.

           Use refs/tags/<tagName> instead.

           E.g. git-2.3.0
      
       refs/tags/<tagName>

           Tracks/checks out the specified tag.

           E.g. refs/tags/git-2.3.0
      
       <commitId>

           Checks out the specified commit.

           E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
      
       ${ENV_VARIABLE}

           It is also possible to use environment variables. In this case the variables are evaluated and the
           result is used as described above.

           E.g. ${TREEISH}, refs/tags/${TAGNAME}, ...
      
       <Wildcards>

           The syntax is of the form: REPOSITORYNAME/BRANCH.
           In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard,
           and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would
           match origin/branches-foo but not origin/branches/foo, while origin/branches** would
           match both origin/branches-foo and origin/branches/foo.
      
       :<regular expression>

           The syntax is of the form: :regexp.
           Regular expression syntax in branches to build will only
           build those branches whose names match the regular
           expression.

           Examples:

            
                :^(?!(origin/prefix)).*
                  
                    matches: origin or origin/master or origin/feature
                    does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
                  
                
                :origin/release-\d{8}
                  
                    matches: origin/release-20150101
                    does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
                  
                
                :^(?!origin/master$|origin/develop$).*
                  
                    matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
                    does not match: origin/master or origin/develop

Type:String

browser


  Defines the repository browser that displays changes detected by the git plugin.

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

gitTool

Name of the git tool to be used for this job. Git tool names are defined in "Global Tool Configuration".

Type:String

extensions


  
  Extensions add new behavior or modify existing plugin behavior for different uses.
  Extensions help users more precisely tune plugin behavior to meet their needs.
  
  
  Extensions include:
    

      
        Clone extensions modify the git operations that retrieve remote changes into the agent workspace.
        The extensions can adjust the amount of history retrieved, how long the retrieval is allowed to run, and other retrieval details.
      
      
        Checkout extensions modify the git operations that place files in the workspace from the git repository on the agent.
        The extensions can adjust the maximum duration of the checkout operation, the use and behavior of git submodules, the location of the workspace on the disc, and more.
      
      
        Changelog extensions adapt the source code difference calculations for different cases.
      
      
        Tagging extensions allow the plugin to apply tags in the current workspace.
      
      
        Build initiation extensions control the conditions that start a build.
        They can ignore notifications of a change or force a deeper evaluation of the commits when polling.
      
      
        Merge extensions can optionally merge changes from other branches into the current branch of the agent workspace.
        They control the source branch for the merge and the options applied to the merge.

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

doGenerateSubmoduleConfigurations (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value and always uses false as its value.

Type:boolean

submoduleCfg (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value(s) and always uses empty values.

Array/List:

Nested object

submoduleName: Removed in git plugin 4.6.0.
Type:String
branches: Removed in git plugin 4.6.0.
Array/List:
Type:String

none

id (optional): Type:String

clone (optional): If checked, every build performs a fresh clone of the SCM rather than locking and updating a common copy. No changelog will be computed. For Git, you are advised to add Advanced clone behaviors and then check Shallow clone and Honor refspec on initial clone and uncheck Fetch tags to make the clone much faster. You may still enable Cache fetched versions on controller for quick retrieval if you prefer.
Type:boolean
libraryPath (optional): A relative path from the root of the SCM to the root of the library. Leave this field blank if the root of the library is the root of the SCM. Note that ".." is not permitted as a path component to avoid security issues.
Type:String

libraryResource: Load a resource file from a library


    Reads a resource from a library and returns its content as a plain string.

resource: Relative (/-separated) path to a resource in a library's /resources folder.
Type:String

encoding (optional): The encoding to use when reading the resource. If left blank, the platform default encoding will be used. Binary files can be read into a Base64-encoded string by specifying "Base64" as the encoding.
Type:String

load: Evaluate a Groovy source file into the Pipeline script


    Takes a filename in the workspace and runs it as Groovy source text.
    
        The loaded file can contain statements at top level or just load and run a closure. For example:
    
        def pipeline
    node('agent') {
        pipeline = load 'pipeline.groovy'
        pipeline.functionA()
    }
    pipeline.functionB()
    
    
    Where pipeline.groovy defines functionA and functionB functions (among others) before ending with return this;

path: Current directory (pwd()) relative path to the Groovy file to load.
Type:String

mail: Mail


    Simple step for sending email.

subject: Email subject line.
Type:String
body: Email body.
Type:String

bcc (optional): BCC email address list. Comma separated list of email addresses.
Type:String
cc (optional): CC email address list. Comma separated list of email addresses.
Type:String
charset (optional): Email body character encoding. Defaults to UTF-8
Type:String
from (optional): From email address. Defaults to the admin address globally configured for the Jenkins instance.
Type:String
mimeType (optional): Email body MIME type. Defaults to text/plain.
Type:String
replyTo (optional): Reply-To email address. Defaults to the admin address globally configured for the Jenkins instance.
Type:String
to (optional): To email address list. Comma separated list of email addresses.
Type:String

milestone: The milestone step forces all builds to go through in order


    By default, Pipeline builds can run concurrently.
    
        The milestone step forces all builds to go through in order, so an older build will never be allowed pass
        a milestone (it is aborted) if a newer build already passed it.
    
    
        In general this step grants:
        

            Builds pass milestones in order (taking the build number as sorter field).
            Older builds will not proceed (they are aborted) if a newer one already passed the milestone.
            When a build passes a milestone, any older build that passed the previous milestone but not this one is aborted.
            Once a build passes the milestone, it will never be aborted by a newer build that didn't pass the milestone yet.

ordinal: An optional ordinal for the milestone. It is autogenerated if not explicitly set.
Setting explicit milestone ordinals grants that each milestone can be univocally identified across builds even when script changes are made during a previous build. If you plan to add or remove milestone steps while there are running builds and trigger new builds before the previous ones finished, then you should set explicit milestone ordinals. Otherwise, let the step autogenerate them as it runs.
Type:int

label (optional): A label for the milestone. It's shown in the build log metadata.
Type:String
unsafe (optional): An optional flag to allow unsafe execution of the milestone step. Do not set unless you understand the risks.
Currently this will allow the execution of a milestone step within a parallel step. It is assumed only 1 branch can contain a milestone step.
Type:boolean

node: Allocate node


    Allocates an executor on a node (typically a build agent) and runs further code in the context of a workspace on that agent.

label



    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)

Type:String

parallel: Execute in parallel

org.kohsuke.stapler.NoStaplerConstructorException: There's no @DataBoundConstructor on any constructor of class org.jenkinsci.plugins.workflow.cps.steps.ParallelStep

powershell: Windows PowerShell Script

script: Executes a Windows PowerShell script (version 3 or later). Multiple lines allowed. Note: be aware of the differences between Windows PowerShell and PowerShell Core, check which one is available on your agents.
Type:String

encoding (optional): 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'
Type:String
label (optional): 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.
Type:String
returnStatus (optional): 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.
Type:boolean
returnStdout (optional): 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.
Type:boolean

properties: Set job properties


    Updates the properties of the job which runs this step.
    Mainly useful from multibranch Pipelines, so that Jenkinsfile itself can encode what would otherwise be static job configuration.
    Existing properties set through the Jenkins UI for non-multibranch Pipelines will be preserved.

properties

Array/List:

Nested choice of objects

authorizationMatrix

entries

Array/List:

Nested choice of objects

group

name: Type:String
permissions: Array/List:
Type:String

user

name: Type:String
permissions: Array/List:
Type:String

userOrGroup

name: Type:String
permissions: Array/List:
Type:String

inheritanceStrategy (optional)

Nested choice of objects

inheritingGlobal

inheriting

nonInheriting

buildDiscarder


  This determines when, if ever, build records for this project should be
  discarded. Build records include the console output, archived artifacts, and
  any other metadata related to a particular build.
  
    Keeping fewer builds means less disk space will be used in the
    Build Record Root Directory
    , which is specified on the
    Configure System
    screen.
  

  
    
    Jenkins offers two options for determining when builds should be discarded:
  

  
    
      Build age: discard builds when they reach a certain age; for example,
      seven days old.
    

    
      Build count: discard the oldest build when a certain number of builds
      already exist.
    
  

  These two options can be active at the same time, so you can keep builds for
  14 days, but only up to a limit of 50 builds, for example. If either limit is
  exceeded, then any builds beyond that limit will be discarded.
  
    You can also ensure that important builds are kept forever, regardless of
    the setting here — click the
    Keep this build forever
    button on the build page.
    

    The last stable and last successful build are also excluded from these
    rules.
  

  

  In the
  Advanced
  section, the same options can be specified, but specifically for build
  artifacts
  . If enabled, build artifacts will be discarded for any builds which exceed
  the defined limits. The builds themselves will still be kept; only the
  associated artifacts, if any, will be deleted.
  
    For example, if a project builds some software and produces a large
    installer, which is archived, you may wish to always keep the console log
    and information about which source control commit was built, while for disk
    space reasons, you may want to keep only the last three installers that were
    built.
    

    This can make sense for projects where you can easily recreate the same
    artifacts later by building the same source control commit again.
  

  

  Note that Jenkins does not discard items immediately when this configuration
  is updated, or as soon as any of the configured values are exceeded; these
  rules are evaluated each time a build of this project completes.

strategy

Nested choice of objects

logRotator

daysToKeepStr: Type:String
numToKeepStr: Type:String
artifactDaysToKeepStr: Type:String
artifactNumToKeepStr: Type:String

removeLastBuild (optional): Type:boolean

disableConcurrentBuilds

abortPrevious (optional): By default, disabling concurrent builds means that new builds will queue up and wait for a running build to complete. With this option, scheduling a new build immediately aborts any running build. This is handy for example if you have an expensive pull request testing procedure and do not wish to waste any time completing tests on an outdated commit.
Type:boolean

disableResume

durabilityHint



    
        This setting allows users to change the default durability mode for running Pipelines.  In most cases this is a
        trade-off between performance and the ability for running pipelines to resume after unplanned Jenkins outages.

        

What does this do?
    

        Previously, running pipelines wrote data constantly, so that they could resume even if Jenkins fails.
            This setting gives the user the ability to adjust this write behavior.
        Higher-performance/lower-durability modes write data to disk much less often for running pipelines.
        Writing data less often can massively reduce build times for Pipelines with many steps or complex logic.
            For pipelines which spend most of their time waiting for a shell/batch script to run, the difference will be less visible.
        Running pipelines with lower durability settings may lose data if they do not finish and Jenkins is not shut down gracefully:
        
            A "graceful" shutdown where Jenkins goes through a full shutdown process, such as visiting http://[jenkins-server]/exit
            A "dirty" shutdown, such as using kill -9 to terminate the Jenkins process, may prevent incomplete pipelines from persisting data
        
        Pipelines that cannot persist data may not be able to resume or displayed in Blue Ocean/Stage View/etc.
        Pipelines will generally write log data regardless of durability settings.
        Some modes use an "atomic write" option - this helps ensure that pipeline build files aren't overwritten or left partially written if something fails.
        Atomic writes may place more stress on filesystems, so especially with networked storage it may be faster not to use them.
    
    
    
        Note:  defaults also be set globally under Manage Jenkins > Configure System.

hint: Values:
PERFORMANCE_OPTIMIZED
SURVIVABLE_NONATOMIC
MAX_SURVIVABILITY

githubProjectProperty

projectUrlStr: Enter the URL for the GitHub hosted project (without the tree/master or tree/branch part). For example: https://github.com/rails/rails for the Rails project.
Type:String

displayName (optional): This value will be used as context name for commit status if status builder or status publisher is defined for this project. It should be small and clear. If you leave it empty, job name will be used for builder and publisher.
Type:String

rateLimitBuilds

throttle



    Enforces a minimum time between builds based on the desired maximum rate. 

    Note: this does
    not enforce an "average" rate, it only looks at the time since last build.

Nested object

count: Type:int
durationName: Type:String
userBoost: Type:boolean

overrideIndexTriggers


    
        Allows overriding default treatment of branch indexing triggers.
    
    
        If branch indexing triggers are disabled at the multibranch or organization label, selecting this will enable them for this job only.
    
    
        Otherwise, leaving the checkbox unselected will disable branch indexing triggers for this job only.

enableTriggers: Type:boolean

parameters


  Parameters allow you to prompt users for one or more inputs that will be
  passed into a build. For example, you might have a project that runs tests on
  demand by allowing users to upload a zip file with binaries to be tested. This
  could be done by adding a
  File Parameter
  here.
  

  Or you might have a project that releases some software, and you want users to
  enter release notes that will be uploaded along with the software. This could
  be done by adding a
  Multi-line String Parameter
  here.
  
    Each parameter has a
    Name
    and some sort of
    Value
    , depending on the parameter type. These name-value pairs will be exported
    as environment variables when the build starts, allowing subsequent parts of
    the build configuration (such as build steps) to access those values, e.g.
    by using the
    ${PARAMETER_NAME}
    syntax (or
    %PARAMETER_NAME%
    on Windows).
    

    This also implies that each parameter defined here should have a unique
    Name
    .
  

  
    When a project is parameterized, the usual
    Build Now
    link will be replaced with a
    Build with Parameters
    link, where users will be prompted to specify values for each of the defined
    parameters. If they choose not to enter anything, the build will start with
    the default value for each parameter.
  

  
    If a build is started automatically, for example if started by an SCM
    trigger, the default values for each parameter will be used.
  

  
    When a parameterized build is in the queue, attempting to start another
    build of the same project will only succeed if the parameter values are
    different, or if the
    Execute concurrent builds if necessary
    option is enabled.
  

  
    See the
    
      Parameterized Builds documentation
    
    for more information about this feature.

parameterDefinitions

Array/List:

Nested choice of objects

booleanParam

name: Type:String

defaultValue (optional): Type:boolean
description (optional): Type:String

choice

name: Type:String

description (optional)

Type:String

choices (optional)

Nested choice of objects: (not enumerable)

credentials


    Defines a credentials parameter, which you can use during a build.
    
    For security reasons, the credential is NOT directly exposed, the ID of the credential is exposed.
    
    However, the selected credential is available through variable substitution in some other parts of the configuration.
    The string value will be the ID of the credential. A supporting plugin can thus use the ID to retrieve
    the selected credential and expose it to the build in an appropriate way.

name: Type:String
defaultValue: The default credentials to use.
Type:String
credentialType: Type:String
required: When this option is selected, the credentials selection drop down will not provide the empty selection as one of the options. This will not prevent a build without a value if there are no credentials available, for example if the job does not have access to any credentials of the correct type or there is no default value and the user starting the build either does not have any credentials of the correct type in their personal credentials store or they do not have permissions on the job to use credentials from their personal store.
Type:boolean

description (optional): Type:String

file

name: Type:String

description (optional): Type:String

password


  Pass a password to your build. The password entered here is made available to
  the build in plain text as an environment variable like a string parameter
  would be. The value will be stored encrypted on the Jenkins controller,
  similar to passwords in Jenkins configuration.

name

Type:String

defaultValueAsSecret

org.kohsuke.stapler.NoStaplerConstructorException: There's no @DataBoundConstructor on any constructor of class hudson.util.Secret

description (optional): Type:String

run

name: Type:String
projectName: Type:String
filter: Values:
ALL
STABLE
SUCCESSFUL
COMPLETED

description (optional): Type:String

string

name: Type:String

defaultValue (optional): Type:String
description (optional): Type:String
trim (optional): Strip whitespace from the beginning and end of the string.
Type:boolean

text

name: Type:String

defaultValue (optional): Type:String
description (optional): Type:String
trim (optional): Strip whitespace from the beginning and end of the string.
Type:boolean

pipelineTriggers

triggers

Array/List:

Nested choice of objects

githubPush

When Jenkins receives a GitHub push hook, GitHub Plugin checks to see
whether the hook came from a GitHub repository which matches the Git repository defined in SCM/Git section of this job.
If they match and this option is enabled, GitHub Plugin triggers a one-time polling on GITScm.
When GITScm polls GitHub, it finds that there is a change and initiates a build.
The last sentence describes the behavior of Git plugin,
thus the polling and initiating the build is not a part of GitHub plugin.

$class: 'PeriodicFolderTrigger'




    
        Some kinds of folders are reindexed automatically and immediately upon receipt of an external event.
        For example, a multi-branch project will recheck its SCM repository for new or removed or modified branches when it receives an SCM change notification.
        (Push notification may be configured as per the SCM plugin used for each respective branch source.)
        Such notifications can occasionally be unreliable, however, or Jenkins might not even be running to receive them.
        In some cases no immediate notification is even possible, for example because Jenkins is behind a firewall and can only poll an external system.
    

    
        This trigger allows for a periodic fallback, but when necessary.
        If no indexing has been performed in the specified interval, then an indexing will be scheduled.
        For example, in the case of a multi-branch project, if the source control system is not configured for push notification, set a short interval (most people will pick between 15 minutes and 1 hour).
        If the source control system is configured for push notification, set an interval that corresponds to the maximum acceptable delay in the event of a lost push notification as the last commit of the day.
        (Subsequent commits should trigger indexing anyway and result in the commit being picked up, so most people will pick between 4 hours and 1 day.)

interval: The maximum amount of time since the last indexing that is allowed to elapse before an indexing is triggered. For example: interval('5m') // or '2h', '7d', '5000ms', '60s'
Type:String

upstream


  
    Set up a trigger so that when some other projects finish building, a new
    build is scheduled for this project. This is convenient for running an
    extensive test after a build is complete, for example.
  
  
    This configuration complements the "Build other projects" section in the
    "Post-build Actions" of an upstream project, but is preferable when you want
    to configure the downstream project.

upstreamProjects: Type:String

threshold (optional): Type:String

pollSCM


  Configure Jenkins to poll changes in SCM.

  
    Note that this is going to be an expensive operation for CVS, as every
    polling requires Jenkins to scan the entire workspace and verify it with the
    server. Consider setting up a "push" trigger to avoid this overhead, as
    described in
    
      this document

scmpoll_spec: Type:String

ignorePostCommitHooks (optional): Ignore changes notified by SCM post-commit hooks. This can be useful if you want to prevent some long-running jobs (e.g. reports) starting because of every commit, but still want to run them periodic if SCM changes have occurred. Note that this option needs to be supported by the SCM plugin, too! The subversion-plugin supports this since version 1.44.
Type:boolean

cron


  Provides a
  cron
  -like feature to periodically execute this project.

  
    This feature is primarily for using Jenkins as a cron replacement, and it is
    not ideal for continuously building software projects
    . When people first start continuous integration, they are often so used to
    the idea of regularly scheduled builds like nightly/weekly that they use
    this feature. However, the point of continuous integration is to start a
    build as soon as a change is made, to provide a quick feedback to the
    change. To do that you need to
    
      hook up SCM change notification to Jenkins
    
    .
  

  
    So, before using this feature, stop and ask yourself if this is really what
    you want.

spec: Type:String

preserveStashes



    Preserve the stashes from the most recent completed builds of this project.
    This allows a restarted Declarative Pipeline to reuse a stash from the build it was restarted from.

buildCount (optional): Type:int

publishChecks: Publish customized checks to SCM platforms

actions (optional)

Array/List:

Nested object

label: The label to be displayed on the checks report for this action.
Type:String
identifier: The unique identifier for the action. Since for SCM platforms like GitHub, this is the only field that would be sent back to your Jenkins instance when an action is requested, so you may need to use this field to have more information besides the basic type of the action.
Type:String

description (optional): Detailed description of the action's purpose, functionality, and so on.
Type:String

annotations (optional)

Array/List:

Nested object

path: Path to the file to be annotated, started from the project root directory.
Type:String
startLine: Start line of code to be annotated.
Type:int
endLine: End line of code to be annotated.
Type:int
message: A digest message of the annotation.
Type:String

annotationLevel (optional): Severity level of the annotation, can be one of can be "NOTICE", "WARNING", or "FAILURE"; by default, "WARNING" will be used.
Values:
NONE
NOTICE
WARNING
FAILURE
endColumn (optional): End column of code to be annotated.
Type:int
rawDetails (optional): Raw details of the annotation.
Type:String
startColumn (optional): Start column of code to be annotated.
Type:int
title (optional): Title of the annotation.
Type:String

conclusion (optional)


    The conclusion of the check, can be "ACTION_REQUIRED", "SKIPPED", "CANCELED", "TIME_OUT", "FAILURE", "NEUTRAL",
    "SUCCESS" or "NONE". By default, "SUCCESS" will be used. When providing the conclusion other than "NONE", please
    make sure the status is "COMPLETED".

Values:

NONE

ACTION_REQUIRED

SKIPPED

CANCELED

TIME_OUT

FAILURE

NEUTRAL

SUCCESS

detailsURL (optional)


    The URL of the site where full details can be found. When providing this parameter, make sure it is http or https
    scheme.

Type:String

name (optional)


    Name or identifier of the check.

Type:String

status (optional)


    The status of the check, can be "QUEUED", "IN_PROGRESS", or "COMPLETED". By default, "COMPLETED" will be used.

Values:

NONE

QUEUED

IN_PROGRESS

COMPLETED

summary (optional)


    The summary of the check run. This field supports Markdown.

Type:String

text (optional)


    The details of the check. This parameter supports Markdown.

Type:String

title (optional)


    The title of the check run.

Type:String

pwd: Determine current directory


    Returns the current directory path as a string.

tmp (optional): If selected, return a temporary directory associated with the current directory path rather than the directory path itself. The return value is different for each current directory. No two directories share the same temporary directory. This is an appropriate place to put temporary files which should not clutter a source checkout; local repositories or caches; etc. Defaults to false.
Type:boolean

pwsh: PowerShell Core Script

script: Executes a PowerShell script. Multiple lines allowed. This plugin supports PowerShell Core 6+. Note: be aware of the differences between Windows PowerShell and PowerShell Core, check which one is available on your agents.
Type:String

encoding (optional): 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'
Type:String
label (optional): 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.
Type:String
returnStatus (optional): 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.
Type:boolean
returnStdout (optional): 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.
Type:boolean

readFile: Read file from workspace


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

file: Relative (/-separated) path to file within a workspace to read.
Type:String

encoding (optional): The encoding to use when reading the file. If left blank, the platform default encoding will be used. Binary files can be read into a Base64-encoded string by specifying "Base64" as the encoding.
Type:String

readScmFile: Read file from SCM


    Loads a (text) file from an SCM repository and returns the contents.
    Unlike readFile this does not require a local checkout or even an agent.
    Unlike readTrusted this does not presume anything about where the Pipeline script came from
    and does not check whether a trusted user committed changes to the file.

scm


    The source control system to use.
    You need only be concerned with repository location and authentication;
    any traits/behaviors may be omitted.
    The id if specified may also be omitted.

Nested choice of objects

github

repoOwner


    Specify the name of the GitHub Organization or GitHub User Account.

Type:String

repository


    The repository to scan.

Type:String

repositoryUrl


    Specify the HTTPS URL of the GitHub Organization / User Account and repository.
    
        GitHub examples:
        

            https://github.com/jenkinsci/github-branch-source-plugin
            https://github.com/jenkinsci/github-branch-source-plugin.git
        
    
    
        GitHub Enterprise examples:
        

            https://myccompany.github.com/jenkinsci/github-branch-source-plugin
            https://myccompany.github.com/jenkinsci/github-branch-source-plugin.git

Type:String

configuredByUrl

Type:boolean

apiUri (optional)


    The server to connect to. The list of servers is configured in the Manage Jenkins » Configure
    System » GitHub Enterprise Servers screen.

Type:String

buildForkPRHead (optional)

Type:boolean

buildForkPRMerge (optional)

Type:boolean

buildOriginBranch (optional)

Type:boolean

buildOriginBranchWithPR (optional)

Type:boolean

buildOriginPRHead (optional)

Type:boolean

buildOriginPRMerge (optional)

Type:boolean

credentialsId (optional)


    
        Credentials used to scan branches and pull requests,
        check out sources and mark commit statuses.
    
    
        Note that only "username with password" credentials are supported.
        Existing credentials of other kinds will be filtered out. This is because Jenkins
        uses the GitHub API, which does not support other ways of authentication.
    
    
        If none is given, only the public repositories will be scanned, and commit status
        will not be set on GitHub.
    
    
        If your organization contains private repositories, then you need to specify
        a credential from a user who has access to those repositories. This is done
        by creating a "username with password" credential where the password is
        GitHub personal access tokens.
        The necessary scope is "repo".

Type:String

excludes (optional)

Type:String

id (optional)

Type:String

includes (optional)

Type:String

traits (optional)


    The behaviours control what is discovered from the GitHub repository. The behaviours are grouped into a number
    of categories:
    
        Within repository
        These behaviours determine what gets discovered. If you do not configure at least one discovery
            behaviour then nothing will be found!
        General
        These behaviours affect the configuration of each discovered branch / pull request.

Array/List:

Nested choice of objects

authorInChangelog

checkoutOption

extension

: timeout
Specify a timeout (in minutes) for checkout.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

cleanAfterCheckout

extension

: Clean up the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cleanBeforeCheckout

extension

: Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cloneOption

extension

: shallow
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
noTags
Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.

Type:boolean
reference
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

Type:String
timeout
Specify a timeout (in minutes) for clone and fetch operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
honorRefspec (optional)
Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.

Type:boolean

discoverOtherRefs


    Discovers other specified refs on the repository.

ref: The pattern under /refs on the remote repository to discover, can contain a wildcard. Example: test/*/merged
Type:String

nameMapping (optional): Mapping for how the ref can be named in for example the @Library. Example: test-@{1} Where @{1} replaces the first wildcard in the ref when discovered.
By default it will be "namespace_before_wildcard-@{1}". E.g. if ref is "test/*/merged" the default mapping would be "test-@{1}".
Type:String

firstBuildChangelog

extension

: First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes. By default, no changelog is generated for the first build because the first build has no predecessor build for comparison. When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional)
Type:boolean

gitHubForkDiscovery


    Discovers pull requests where the origin repository is a fork of the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

trust


    
        One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit
        some changes to their fork and then create a pull request against the original repository with their changes.
        There are some files stored in source control that are important. For example, a Jenkinsfile
        may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests.
        In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove
        the protections, you can define the trust policy for pull requests from forks.
    
    
        Other plugins can extend the available trust policies. The default policies are:
    
    
        Nobody
        
            Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a
            trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the
            target branch on the origin repository and not from the pull request branch on the fork repository.
        
        Collaborators
        
            Pull requests from collaborators
            to the origin repository will be treated as trusted, all other pull requests from fork repositories
            will be treated as untrusted.
            Note that if credentials used by Jenkins for scanning the repository does not have permission to
            query the list of collaborators to the origin repository then only the origin account will be treated
            as trusted - i.e. this will fall back to Nobody.
            NOTE: all collaborators are trusted, even if they are only members of a team with read permission.
        
        Everyone
        
            All pull requests from forks will be treated as trusted. NOTE: this option can be dangerous
            if used on a public repository hosted on GitHub.
        
        From users with Admin or Write permission
        
            Pull requests forks will be treated as trusted if and only if the fork owner has either Admin or Write
            permissions on the origin repository.
            This is the recommended policy.
            Note that this strategy requires the
            Review
            a user's permission level API, as a result on GitHub Enterprise Server versions before 2.12 this
            is the same as trusting Nobody.

Nested choice of objects

gitHubTrustContributors

gitHubTrustEveryone

gitHubTrustNobody

gitHubTrustPermissions

browser

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

lfs

gitTool

gitTool: Type:String

gitHubIgnoreDraftPullRequestFilter

ignoreOnPush

localBranch

multiBranchProjectDisplayNaming


    Some branch source plugins provide additional information about discovered branches like a title or subject of merge or change requests.

    With this trait, that additional information can be used for the job display names.

    Note: Job display name changes do not trigger builds.

displayNamingStrategy


  The different strategies:
  
    
      
        Job display name with fallback to name:
        

        Uses the branch source plugin's display name for the PR instead of the raw name
        

        Value for configuration-as-code: OBJECT_DISPLAY_NAME
      
    
    
      
        Name and, if available, display name:
        

        Joins the raw name and the branch source plugin's display name
        

        Value for configuration-as-code: RAW_AND_OBJECT_DISPLAY_NAME
      
    
    
      
        Simple name:
        

        Just the raw name
        

        Value for configuration-as-code: RAW

Values:

OBJECT_DISPLAY_NAME

RAW_AND_OBJECT_DISPLAY_NAME

RAW

gitHubPullRequestDiscovery


    Discovers pull requests where the origin repository is the same as the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

pruneStaleBranch

pruneStaleTag

refSpecs

templates

Array/List:

Nested object

value: A ref spec to fetch. Any occurrences of @{remote} will be replaced by the remote name (which defaults to origin) before use.
Type:String

headRegexFilter

regex: A Java regular expression to restrict the names. Names that do not match the supplied regular expression will be ignored. NOTE: this filter will be applied to all branch like things, including change requests
Type:String

remoteName

remoteName: Type:String

gitHubSshCheckout


    By default the discovered branches / pull requests will all use the same username / password credentials
    that were used for discovery when checking out sources. This means that the checkout will be using the
    https:// protocol for the Git repository.
    
        This behaviour allows you to select the SSH private key to be used for checking out sources, which will
        consequently force the checkout to use the ssh:// protocol.

credentialsId: Credentials used to check out sources. Must be a SSH key based credential.
Type:String

sparseCheckoutPaths

extension

: Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths
Array/List:
Nested object
path
Type:String

submoduleOption

extension

: depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
disableSubmodules (optional)
By disabling support for submodules you can still keep using basic git plugin functionality and just have Jenkins to ignore submodules completely as if they didn't exist.

Type:boolean
parentCredentials (optional)
Use credentials from the default remote of the parent project.

Type:boolean
recursiveSubmodules (optional)
Retrieve all submodules recursively (uses '--recursive' option which requires git>=1.6.5)

Type:boolean
reference (optional)
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

git init --bare git remote add SubProject1 https://gitrepo.com/subproject1 git remote add SubProject2 https://gitrepo.com/subproject2 git fetch --all

Type:String
shallow (optional)
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
threads (optional)
Specify the number of threads that will be used to update submodules.
If unspecified, the command line git default thread count is used.

Type:int
timeout (optional)
Specify a timeout (in minutes) for submodules operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
trackingSubmodules (optional)
Retrieve the tip of the configured branch in .gitmodules (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

userIdentity

extension

Nested object

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

headWildcardFilter

includes: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release* NOTE: this filter will be applied to all branch like things, including change requests
Type:String
excludes: Space-separated list of name patterns to ignore even if matched by the includes list. For example: release alpha-* beta-* NOTE: this filter will be applied to all branch like things, including change requests
Type:String

$class: 'WipeWorkspaceTrait'

gitBranchDiscovery


    Discovers branches on the repository.

gitTagDiscovery


    Discovers tags on the repository.

gitHubBranchDiscovery


    Discovers branches on the repository.

strategyId


    Determines which branches are discovered.
    
        Exclude branches that are also filed as PRs
        
            If you are discovering origin pull requests, you may not want to also build the source branches
            for those pull requests.
        
        Only branches that are also filed as PRs
        
            Similar to discovering origin pull requests, but discovers the branch rather than the pull request. 
            This means env.GIT_BRANCH will be set to the branch name rather than PR-#.
            Also, status notifications for these builds will only be applied to the commit and not to the pull request.
        
        All branches
        
            Ignores whether the branch is also filed as a pull request and instead discovers all branches on the
            origin repository.

Type:int

gitHubTagDiscovery


    Discovers tags on the repository.

gitSource

remote: Specify the URL of this remote repository. This uses the same syntax as your git clone command.
Type:String

browser (optional)

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

credentialsId (optional)




    Credentials used to scan branches and check out sources.

Type:String

extensions (optional)

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

gitTool (optional)

Type:String

id (optional)

Type:String

traits (optional)

Array/List:

Nested choice of objects

authorInChangelog

checkoutOption

extension

: timeout
Specify a timeout (in minutes) for checkout.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

cleanAfterCheckout

extension

: Clean up the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cleanBeforeCheckout

extension

: Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cloneOption

extension

: shallow
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
noTags
Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.

Type:boolean
reference
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

Type:String
timeout
Specify a timeout (in minutes) for clone and fetch operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
honorRefspec (optional)
Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.

Type:boolean

discoverOtherRefs


    Discovers other specified refs on the repository.

ref: The pattern under /refs on the remote repository to discover, can contain a wildcard. Example: test/*/merged
Type:String

nameMapping (optional): Mapping for how the ref can be named in for example the @Library. Example: test-@{1} Where @{1} replaces the first wildcard in the ref when discovered.
By default it will be "namespace_before_wildcard-@{1}". E.g. if ref is "test/*/merged" the default mapping would be "test-@{1}".
Type:String

firstBuildChangelog

extension

: First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes. By default, no changelog is generated for the first build because the first build has no predecessor build for comparison. When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional)
Type:boolean

gitHubForkDiscovery


    Discovers pull requests where the origin repository is a fork of the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

trust


    
        One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit
        some changes to their fork and then create a pull request against the original repository with their changes.
        There are some files stored in source control that are important. For example, a Jenkinsfile
        may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests.
        In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove
        the protections, you can define the trust policy for pull requests from forks.
    
    
        Other plugins can extend the available trust policies. The default policies are:
    
    
        Nobody
        
            Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a
            trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the
            target branch on the origin repository and not from the pull request branch on the fork repository.
        
        Collaborators
        
            Pull requests from collaborators
            to the origin repository will be treated as trusted, all other pull requests from fork repositories
            will be treated as untrusted.
            Note that if credentials used by Jenkins for scanning the repository does not have permission to
            query the list of collaborators to the origin repository then only the origin account will be treated
            as trusted - i.e. this will fall back to Nobody.
            NOTE: all collaborators are trusted, even if they are only members of a team with read permission.
        
        Everyone
        
            All pull requests from forks will be treated as trusted. NOTE: this option can be dangerous
            if used on a public repository hosted on GitHub.
        
        From users with Admin or Write permission
        
            Pull requests forks will be treated as trusted if and only if the fork owner has either Admin or Write
            permissions on the origin repository.
            This is the recommended policy.
            Note that this strategy requires the
            Review
            a user's permission level API, as a result on GitHub Enterprise Server versions before 2.12 this
            is the same as trusting Nobody.

Nested choice of objects

gitHubTrustContributors

gitHubTrustEveryone

gitHubTrustNobody

gitHubTrustPermissions

browser

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

lfs

gitTool

gitTool: Type:String

gitHubIgnoreDraftPullRequestFilter

ignoreOnPush

localBranch

multiBranchProjectDisplayNaming


    Some branch source plugins provide additional information about discovered branches like a title or subject of merge or change requests.

    With this trait, that additional information can be used for the job display names.

    Note: Job display name changes do not trigger builds.

displayNamingStrategy


  The different strategies:
  
    
      
        Job display name with fallback to name:
        

        Uses the branch source plugin's display name for the PR instead of the raw name
        

        Value for configuration-as-code: OBJECT_DISPLAY_NAME
      
    
    
      
        Name and, if available, display name:
        

        Joins the raw name and the branch source plugin's display name
        

        Value for configuration-as-code: RAW_AND_OBJECT_DISPLAY_NAME
      
    
    
      
        Simple name:
        

        Just the raw name
        

        Value for configuration-as-code: RAW

Values:

OBJECT_DISPLAY_NAME

RAW_AND_OBJECT_DISPLAY_NAME

RAW

gitHubPullRequestDiscovery


    Discovers pull requests where the origin repository is the same as the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

pruneStaleBranch

pruneStaleTag

refSpecs

templates

Array/List:

Nested object

value: A ref spec to fetch. Any occurrences of @{remote} will be replaced by the remote name (which defaults to origin) before use.
Type:String

headRegexFilter

regex: A Java regular expression to restrict the names. Names that do not match the supplied regular expression will be ignored. NOTE: this filter will be applied to all branch like things, including change requests
Type:String

remoteName

remoteName: Type:String

gitHubSshCheckout


    By default the discovered branches / pull requests will all use the same username / password credentials
    that were used for discovery when checking out sources. This means that the checkout will be using the
    https:// protocol for the Git repository.
    
        This behaviour allows you to select the SSH private key to be used for checking out sources, which will
        consequently force the checkout to use the ssh:// protocol.

credentialsId: Credentials used to check out sources. Must be a SSH key based credential.
Type:String

sparseCheckoutPaths

extension

: Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths
Array/List:
Nested object
path
Type:String

submoduleOption

extension

: depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
disableSubmodules (optional)
By disabling support for submodules you can still keep using basic git plugin functionality and just have Jenkins to ignore submodules completely as if they didn't exist.

Type:boolean
parentCredentials (optional)
Use credentials from the default remote of the parent project.

Type:boolean
recursiveSubmodules (optional)
Retrieve all submodules recursively (uses '--recursive' option which requires git>=1.6.5)

Type:boolean
reference (optional)
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

git init --bare git remote add SubProject1 https://gitrepo.com/subproject1 git remote add SubProject2 https://gitrepo.com/subproject2 git fetch --all

Type:String
shallow (optional)
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
threads (optional)
Specify the number of threads that will be used to update submodules.
If unspecified, the command line git default thread count is used.

Type:int
timeout (optional)
Specify a timeout (in minutes) for submodules operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
trackingSubmodules (optional)
Retrieve the tip of the configured branch in .gitmodules (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

userIdentity

extension

Nested object

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

headWildcardFilter

includes: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release* NOTE: this filter will be applied to all branch like things, including change requests
Type:String
excludes: Space-separated list of name patterns to ignore even if matched by the includes list. For example: release alpha-* beta-* NOTE: this filter will be applied to all branch like things, including change requests
Type:String

$class: 'WipeWorkspaceTrait'

gitBranchDiscovery


    Discovers branches on the repository.

gitTagDiscovery


    Discovers tags on the repository.

gitHubBranchDiscovery


    Discovers branches on the repository.

strategyId


    Determines which branches are discovered.
    
        Exclude branches that are also filed as PRs
        
            If you are discovering origin pull requests, you may not want to also build the source branches
            for those pull requests.
        
        Only branches that are also filed as PRs
        
            Similar to discovering origin pull requests, but discovers the branch rather than the pull request. 
            This means env.GIT_BRANCH will be set to the branch name rather than PR-#.
            Also, status notifications for these builds will only be applied to the commit and not to the pull request.
        
        All branches
        
            Ignores whether the branch is also filed as a pull request and instead discovers all branches on the
            origin repository.

Type:int

gitHubTagDiscovery


    Discovers tags on the repository.

fromScm

name


    The name of the SCM head/trunk/branch/tag that this source provides.

Type:String

scm

Nested choice of objects

scmGit


  
  The git plugin provides fundamental git operations for Jenkins projects.
  It can poll, fetch, checkout, and merge contents of git repositories.
  

  
  The scmGit parameter of the git plugin is used with the Pipeline SCM checkout step to checkout git repositories into Pipeline workspaces.
  The Pipeline Syntax Snippet Generator guides the user to select git plugin checkout options and provides online help for each of the options.
  


    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    Examples of the checkout step include:
    

      Checkout step with defaults
      Checkout step with https and a specific branch
      Checkout step with ssh and a private key credential
      Checkout step with https and changelog disabled
      Checkout step with git protocol and polling disabled
    
    See the argument descriptions for more details.
    

    
    The scmGit parameter of the checkout step provides access to all the Pipeline capabilities provided by the git plugin:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    

    
    NOTE: The checkout step with the scmGit parameter is the preferred SCM checkout method.
    For simpler cases that do not require all the capabilities of the git plugin, the git step can also be used.
    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    
    
    The checkout step with the scmGit parameter can be used in many cases where the git step cannot be used.
    Refer to the git plugin documentation for detailed descriptions of options available to the checkout step.
    For example, the checkout step supports:
    

      SHA-1 checkout
      Tag checkout
      Submodule checkout
      Sparse checkout
      Large file checkout (LFS)
      Reference repositories
      Branch merges
      Repository tagging
      Custom refspecs
      Timeout configuration
      Changelog calculation against a non-default reference
      Stale branch pruning
    
    

    

    Example: Checkout step with defaults
    
    Checkout from the git plugin source repository using https protocol, no credentials, and the master branch.
    
The Pipeline Snippet Generator generates this example:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    Example: Checkout step with https and a specific branch
    
    Checkout from the Jenkins source repository using https protocol, no credentials, and a specific branch (stable-2.289).
    
    The Pipeline Snippet Generator generates this example:
checkout scmGit(branches: [[name: 'stable-2.289']],
                userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/jenkins.git' ]
                ])

    

    Example: Checkout step with ssh and a private key credential
    
    Checkout from the git client plugin source repository using ssh protocol, private key credentials, and the master branch.
    The credential must be a private key credential if the remote git repository is accessed with the ssh protocol.
    The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ credentialsId: 'my-private-key-credential-id',
                           url: 'git@github.com:jenkinsci/git-client-plugin.git' ]
                     ])

    

    Example: Checkout step with https and changelog disabled
    
    Checkout from the Jenkins source repository using https protocol, no credentials, the master branch, and changelog calculation disabled.
    If changelog is false, then the changelog will not be computed for this job.
    If changelog is true or is not set, then the changelog will be computed.
    See the workflow scm step documentation for more changelog details.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'https://github.com/jenkinsci/credentials-plugin' ]
                     ])

    

    Example: Checkout step with git protocol and polling disabled
    
    Checkout from the command line git repository using git protocol, no credentials, the master branch, and no polling for changes.
    If poll is false, then the remote repository will not be polled for changes.
    If poll is true or is not set, then the remote repository will be polled for changes.
    See the workflow scm step documentation for more polling details.
    
The Pipeline Snippet Generator generates this example:
checkout poll: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'git://git.kernel.org/pub/scm/git/git.git' ]
                     ])

    

    

    Argument Descriptions

userRemoteConfigs


  Specify the repository to track. This can be a URL or a local file path.
  Note that for super-projects (repositories with submodules), only a local file
  path or a complete URL is valid.  The following are examples of valid git URLs.
  
    ssh://git@github.com/github/git.git
    git@github.com:github/git.git (short notation for ssh protocol)
    ssh://user@other.host.com/~/repos/R.git (to access the repos/R.git
    repository in the user's home directory)
    https://github.com/github/git.git
  
  

  If the repository is a super-project, the
  location from which to clone submodules is dependent on whether the repository
  is bare or non-bare (i.e. has a working directory).
  
    If the super-project is bare, the location of the submodules will be
    taken from .gitmodules.
    If the super-project is not bare, it is assumed that the
    repository has each of its submodules cloned and checked out appropriately.
    Thus, the submodules will be taken directly from a path like
    ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on
    information from .gitmodules.
  

  For a local URL/path to a super-project,
  git rev-parse --is-bare-repository
  is used to detect whether the super-project is bare or not.
  

  For a remote URL to a super-project, the ending of the URL determines whether
  a bare or non-bare repository is assumed:
  
    If the remote URL ends with .git, a non-bare repository is
    assumed.
    If the remote URL does NOT end with .git, a bare
    repository is assumed.

Array/List:

Nested object

url: Specify the URL or path of the git repository. This uses the same syntax as your git clone command.
Type:String
name: ID of the repository, such as origin, to uniquely identify this repository among other remote repositories. This is the same "name" that you use in your git remote command. If left empty, Jenkins will generate unique names for you. You normally want to specify this when you have multiple remote repositories.
Type:String
refspec: A refspec controls the remote refs to be retrieved and how they map to local refs. If left blank, it will default to the normal behaviour of git fetch, which retrieves all the branch heads as remotes/REPOSITORYNAME/BRANCHNAME. This default behaviour is OK for most cases. In other words, the default refspec is "+refs/heads/*:refs/remotes/REPOSITORYNAME/*" where REPOSITORYNAME is the value you specify in the above "name of repository" textbox. When do you want to modify this value? A good example is when you want to just retrieve one branch. For example, +refs/heads/master:refs/remotes/origin/master would only retrieve the master branch and nothing else. The plugin uses a default refspec for its initial fetch, unless the "Advanced Clone Option" is set to honor refspec. This keeps compatibility with previous behavior, and allows the job definition to decide if the refspec should be honored on initial clone. Multiple refspecs can be entered by separating them with a space character. +refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop retrieves the master branch and the develop branch and nothing else. See the refspec definition in Git user manual for more details.
Type:String
credentialsId: Credential used to check out sources.
Type:String

branches


  List of branches to build.
  Jenkins jobs are most effective when each job builds only a single branch.
  When a single job builds multiple branches, the changelog comparisons between branches often show no changes or incorrect changes.

Array/List:

Nested object

name


  Specify the branches if you'd like to track a specific branch in a repository.
  If left blank, all branches will be examined for changes and built.

  The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch
  is unambiguous.

  If your branch name has a / in it make sure to use the full reference above. When not presented
  with a full path the plugin will only use the part of the string right of the last slash.
  Meaning foo/bar will actually match bar.

  If you use a wildcard branch specifier, with a slash (e.g. release/),
  you'll need to specify the origin repository in the branch names to
  make sure changes are picked up. So e.g. origin/release/

  Possible options:
    

       <branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one. Better use refs/heads/<branchName>.

           E.g. master, feature1, ...
      
       refs/heads/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/heads/master, refs/heads/feature1/master, ...
      
       <remoteRepoName>/<branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one.

           Better use refs/heads/<branchName>.

           E.g. origin/master
      
       remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. remotes/origin/master
      
       refs/remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/remotes/origin/master
      
       <tagName>

           This does not work since the tag will not be recognized as tag.

           Use refs/tags/<tagName> instead.

           E.g. git-2.3.0
      
       refs/tags/<tagName>

           Tracks/checks out the specified tag.

           E.g. refs/tags/git-2.3.0
      
       <commitId>

           Checks out the specified commit.

           E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
      
       ${ENV_VARIABLE}

           It is also possible to use environment variables. In this case the variables are evaluated and the
           result is used as described above.

           E.g. ${TREEISH}, refs/tags/${TAGNAME}, ...
      
       <Wildcards>

           The syntax is of the form: REPOSITORYNAME/BRANCH.
           In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard,
           and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would
           match origin/branches-foo but not origin/branches/foo, while origin/branches** would
           match both origin/branches-foo and origin/branches/foo.
      
       :<regular expression>

           The syntax is of the form: :regexp.
           Regular expression syntax in branches to build will only
           build those branches whose names match the regular
           expression.

           Examples:

            
                :^(?!(origin/prefix)).*
                  
                    matches: origin or origin/master or origin/feature
                    does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
                  
                
                :origin/release-\d{8}
                  
                    matches: origin/release-20150101
                    does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
                  
                
                :^(?!origin/master$|origin/develop$).*
                  
                    matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
                    does not match: origin/master or origin/develop

Type:String

browser


  Defines the repository browser that displays changes detected by the git plugin.

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

gitTool

Name of the git tool to be used for this job. Git tool names are defined in "Global Tool Configuration".

Type:String

extensions


  
  Extensions add new behavior or modify existing plugin behavior for different uses.
  Extensions help users more precisely tune plugin behavior to meet their needs.
  
  
  Extensions include:
    

      
        Clone extensions modify the git operations that retrieve remote changes into the agent workspace.
        The extensions can adjust the amount of history retrieved, how long the retrieval is allowed to run, and other retrieval details.
      
      
        Checkout extensions modify the git operations that place files in the workspace from the git repository on the agent.
        The extensions can adjust the maximum duration of the checkout operation, the use and behavior of git submodules, the location of the workspace on the disc, and more.
      
      
        Changelog extensions adapt the source code difference calculations for different cases.
      
      
        Tagging extensions allow the plugin to apply tags in the current workspace.
      
      
        Build initiation extensions control the conditions that start a build.
        They can ignore notifications of a change or force a deeper evaluation of the commits when polling.
      
      
        Merge extensions can optionally merge changes from other branches into the current branch of the agent workspace.
        They control the source branch for the merge and the options applied to the merge.

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

doGenerateSubmoduleConfigurations (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value and always uses false as its value.

Type:boolean

submoduleCfg (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value(s) and always uses empty values.

Array/List:

Nested object

submoduleName: Removed in git plugin 4.6.0.
Type:String
branches: Removed in git plugin 4.6.0.
Array/List:
Type:String

none

id (optional): Type:String

version


    The version of files to load.
    Could be a branch or tag name, commit hash, etc., according to the SCM.

Type:String

path


    The relative path from the repository root, like directory/file.yaml.

Type:String

readTrusted: Read trusted file from SCM


    From a multibranch Pipeline project, reads a file from the associated SCM and returns its contents.
    Unlike the readFile step, no workspace is required.
    If the associated branch is not trusted, yet the file has been modified from its trusted version, an error is thrown.
    Thus this step is useful for loading scripts or other files which might otherwise be used to run malicious commands.
    Like checkout scm, as a convenience it may also be used from a standalone project configured with Pipeline from SCM,
    in which case there is no security aspect.

path: Relative (slash-separated) path to the file from the SCM root. Thus readTrusted 'subdir/file' is similar to node {checkout scm; readFile 'subdir/file'}.
Type:String

resolveScm: Resolves an SCM from an SCM Source and a list of candidate target branch names



    When you have a multi-branch pipeline that checks out other sibling repositories, you may want to check out the
    matching branch from that sibling repository (assuming it exists) but fall back to the main branch if there is no
    matching branch.
    
    This step lets you create a branch in the primary repository and then when you need downstream / upstream changes in
    the sibling repository you can just create a matching branch and it will be resolved automatically.
    For example:
    
// checkout the main source
dir('main'){
    // this will checkout the source repository that is driving the multi-branch pipeline
    checkout scm
}
// now checkout the tests
dir('tests'){
    // this will check if there is a branch with the same name as the current branch in
    // https://example.com/example.git and use that for the checkout, but if there is no
    // branch with the same name it will fall back to the master branch
    checkout resolveScm(source: git('https://example.com/example.git'), targets: [BRANCH_NAME,'master']
}
// rest of pipeline

    
    The return value is the resolved SCM instance (or null if ignoring errors).
    Where the SCM implementation supports it, the SCM instance will be pinned to the current head revision of
    the resolved branch. This can be useful if, for example, you want to check out the resolved branch on
    multiple nodes because all the nodes will get the same revision.

source



    The source repository from which to resolve the target branches.

Nested choice of objects

github

repoOwner


    Specify the name of the GitHub Organization or GitHub User Account.

Type:String

repository


    The repository to scan.

Type:String

repositoryUrl


    Specify the HTTPS URL of the GitHub Organization / User Account and repository.
    
        GitHub examples:
        

            https://github.com/jenkinsci/github-branch-source-plugin
            https://github.com/jenkinsci/github-branch-source-plugin.git
        
    
    
        GitHub Enterprise examples:
        

            https://myccompany.github.com/jenkinsci/github-branch-source-plugin
            https://myccompany.github.com/jenkinsci/github-branch-source-plugin.git

Type:String

configuredByUrl

Type:boolean

apiUri (optional)


    The server to connect to. The list of servers is configured in the Manage Jenkins » Configure
    System » GitHub Enterprise Servers screen.

Type:String

buildForkPRHead (optional)

Type:boolean

buildForkPRMerge (optional)

Type:boolean

buildOriginBranch (optional)

Type:boolean

buildOriginBranchWithPR (optional)

Type:boolean

buildOriginPRHead (optional)

Type:boolean

buildOriginPRMerge (optional)

Type:boolean

credentialsId (optional)


    
        Credentials used to scan branches and pull requests,
        check out sources and mark commit statuses.
    
    
        Note that only "username with password" credentials are supported.
        Existing credentials of other kinds will be filtered out. This is because Jenkins
        uses the GitHub API, which does not support other ways of authentication.
    
    
        If none is given, only the public repositories will be scanned, and commit status
        will not be set on GitHub.
    
    
        If your organization contains private repositories, then you need to specify
        a credential from a user who has access to those repositories. This is done
        by creating a "username with password" credential where the password is
        GitHub personal access tokens.
        The necessary scope is "repo".

Type:String

excludes (optional)

Type:String

id (optional)

Type:String

includes (optional)

Type:String

traits (optional)


    The behaviours control what is discovered from the GitHub repository. The behaviours are grouped into a number
    of categories:
    
        Within repository
        These behaviours determine what gets discovered. If you do not configure at least one discovery
            behaviour then nothing will be found!
        General
        These behaviours affect the configuration of each discovered branch / pull request.

Array/List:

Nested choice of objects

authorInChangelog

checkoutOption

extension

: timeout
Specify a timeout (in minutes) for checkout.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

cleanAfterCheckout

extension

: Clean up the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cleanBeforeCheckout

extension

: Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cloneOption

extension

: shallow
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
noTags
Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.

Type:boolean
reference
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

Type:String
timeout
Specify a timeout (in minutes) for clone and fetch operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
honorRefspec (optional)
Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.

Type:boolean

discoverOtherRefs


    Discovers other specified refs on the repository.

ref: The pattern under /refs on the remote repository to discover, can contain a wildcard. Example: test/*/merged
Type:String

nameMapping (optional): Mapping for how the ref can be named in for example the @Library. Example: test-@{1} Where @{1} replaces the first wildcard in the ref when discovered.
By default it will be "namespace_before_wildcard-@{1}". E.g. if ref is "test/*/merged" the default mapping would be "test-@{1}".
Type:String

firstBuildChangelog

extension

: First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes. By default, no changelog is generated for the first build because the first build has no predecessor build for comparison. When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional)
Type:boolean

gitHubForkDiscovery


    Discovers pull requests where the origin repository is a fork of the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

trust


    
        One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit
        some changes to their fork and then create a pull request against the original repository with their changes.
        There are some files stored in source control that are important. For example, a Jenkinsfile
        may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests.
        In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove
        the protections, you can define the trust policy for pull requests from forks.
    
    
        Other plugins can extend the available trust policies. The default policies are:
    
    
        Nobody
        
            Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a
            trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the
            target branch on the origin repository and not from the pull request branch on the fork repository.
        
        Collaborators
        
            Pull requests from collaborators
            to the origin repository will be treated as trusted, all other pull requests from fork repositories
            will be treated as untrusted.
            Note that if credentials used by Jenkins for scanning the repository does not have permission to
            query the list of collaborators to the origin repository then only the origin account will be treated
            as trusted - i.e. this will fall back to Nobody.
            NOTE: all collaborators are trusted, even if they are only members of a team with read permission.
        
        Everyone
        
            All pull requests from forks will be treated as trusted. NOTE: this option can be dangerous
            if used on a public repository hosted on GitHub.
        
        From users with Admin or Write permission
        
            Pull requests forks will be treated as trusted if and only if the fork owner has either Admin or Write
            permissions on the origin repository.
            This is the recommended policy.
            Note that this strategy requires the
            Review
            a user's permission level API, as a result on GitHub Enterprise Server versions before 2.12 this
            is the same as trusting Nobody.

Nested choice of objects

gitHubTrustContributors

gitHubTrustEveryone

gitHubTrustNobody

gitHubTrustPermissions

browser

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

lfs

gitTool

gitTool: Type:String

gitHubIgnoreDraftPullRequestFilter

ignoreOnPush

localBranch

multiBranchProjectDisplayNaming


    Some branch source plugins provide additional information about discovered branches like a title or subject of merge or change requests.

    With this trait, that additional information can be used for the job display names.

    Note: Job display name changes do not trigger builds.

displayNamingStrategy


  The different strategies:
  
    
      
        Job display name with fallback to name:
        

        Uses the branch source plugin's display name for the PR instead of the raw name
        

        Value for configuration-as-code: OBJECT_DISPLAY_NAME
      
    
    
      
        Name and, if available, display name:
        

        Joins the raw name and the branch source plugin's display name
        

        Value for configuration-as-code: RAW_AND_OBJECT_DISPLAY_NAME
      
    
    
      
        Simple name:
        

        Just the raw name
        

        Value for configuration-as-code: RAW

Values:

OBJECT_DISPLAY_NAME

RAW_AND_OBJECT_DISPLAY_NAME

RAW

gitHubPullRequestDiscovery


    Discovers pull requests where the origin repository is the same as the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

pruneStaleBranch

pruneStaleTag

refSpecs

templates

Array/List:

Nested object

value: A ref spec to fetch. Any occurrences of @{remote} will be replaced by the remote name (which defaults to origin) before use.
Type:String

headRegexFilter

regex: A Java regular expression to restrict the names. Names that do not match the supplied regular expression will be ignored. NOTE: this filter will be applied to all branch like things, including change requests
Type:String

remoteName

remoteName: Type:String

gitHubSshCheckout


    By default the discovered branches / pull requests will all use the same username / password credentials
    that were used for discovery when checking out sources. This means that the checkout will be using the
    https:// protocol for the Git repository.
    
        This behaviour allows you to select the SSH private key to be used for checking out sources, which will
        consequently force the checkout to use the ssh:// protocol.

credentialsId: Credentials used to check out sources. Must be a SSH key based credential.
Type:String

sparseCheckoutPaths

extension

: Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths
Array/List:
Nested object
path
Type:String

submoduleOption

extension

: depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
disableSubmodules (optional)
By disabling support for submodules you can still keep using basic git plugin functionality and just have Jenkins to ignore submodules completely as if they didn't exist.

Type:boolean
parentCredentials (optional)
Use credentials from the default remote of the parent project.

Type:boolean
recursiveSubmodules (optional)
Retrieve all submodules recursively (uses '--recursive' option which requires git>=1.6.5)

Type:boolean
reference (optional)
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

git init --bare git remote add SubProject1 https://gitrepo.com/subproject1 git remote add SubProject2 https://gitrepo.com/subproject2 git fetch --all

Type:String
shallow (optional)
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
threads (optional)
Specify the number of threads that will be used to update submodules.
If unspecified, the command line git default thread count is used.

Type:int
timeout (optional)
Specify a timeout (in minutes) for submodules operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
trackingSubmodules (optional)
Retrieve the tip of the configured branch in .gitmodules (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

userIdentity

extension

Nested object

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

headWildcardFilter

includes: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release* NOTE: this filter will be applied to all branch like things, including change requests
Type:String
excludes: Space-separated list of name patterns to ignore even if matched by the includes list. For example: release alpha-* beta-* NOTE: this filter will be applied to all branch like things, including change requests
Type:String

$class: 'WipeWorkspaceTrait'

gitBranchDiscovery


    Discovers branches on the repository.

gitTagDiscovery


    Discovers tags on the repository.

gitHubBranchDiscovery


    Discovers branches on the repository.

strategyId


    Determines which branches are discovered.
    
        Exclude branches that are also filed as PRs
        
            If you are discovering origin pull requests, you may not want to also build the source branches
            for those pull requests.
        
        Only branches that are also filed as PRs
        
            Similar to discovering origin pull requests, but discovers the branch rather than the pull request. 
            This means env.GIT_BRANCH will be set to the branch name rather than PR-#.
            Also, status notifications for these builds will only be applied to the commit and not to the pull request.
        
        All branches
        
            Ignores whether the branch is also filed as a pull request and instead discovers all branches on the
            origin repository.

Type:int

gitHubTagDiscovery


    Discovers tags on the repository.

gitSource

remote: Specify the URL of this remote repository. This uses the same syntax as your git clone command.
Type:String

browser (optional)

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

credentialsId (optional)




    Credentials used to scan branches and check out sources.

Type:String

extensions (optional)

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

gitTool (optional)

Type:String

id (optional)

Type:String

traits (optional)

Array/List:

Nested choice of objects

authorInChangelog

checkoutOption

extension

: timeout
Specify a timeout (in minutes) for checkout.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

cleanAfterCheckout

extension

: Clean up the workspace after every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cleanBeforeCheckout

extension

: Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional)
Deletes untracked submodules and any other subdirectories which contain .git directories.

Type:boolean

cloneOption

extension

: shallow
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
noTags
Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.

Type:boolean
reference
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

Type:String
timeout
Specify a timeout (in minutes) for clone and fetch operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
honorRefspec (optional)
Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.

Type:boolean

discoverOtherRefs


    Discovers other specified refs on the repository.

ref: The pattern under /refs on the remote repository to discover, can contain a wildcard. Example: test/*/merged
Type:String

nameMapping (optional): Mapping for how the ref can be named in for example the @Library. Example: test-@{1} Where @{1} replaces the first wildcard in the ref when discovered.
By default it will be "namespace_before_wildcard-@{1}". E.g. if ref is "test/*/merged" the default mapping would be "test-@{1}".
Type:String

firstBuildChangelog

extension

: First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes. By default, no changelog is generated for the first build because the first build has no predecessor build for comparison. When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional)
Type:boolean

gitHubForkDiscovery


    Discovers pull requests where the origin repository is a fork of the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

trust


    
        One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit
        some changes to their fork and then create a pull request against the original repository with their changes.
        There are some files stored in source control that are important. For example, a Jenkinsfile
        may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests.
        In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove
        the protections, you can define the trust policy for pull requests from forks.
    
    
        Other plugins can extend the available trust policies. The default policies are:
    
    
        Nobody
        
            Pull requests from forks will all be treated as untrusted. This means that where Jenkins requires a
            trusted file (e.g. Jenkinsfile) the contents of that file will be retrieved from the
            target branch on the origin repository and not from the pull request branch on the fork repository.
        
        Collaborators
        
            Pull requests from collaborators
            to the origin repository will be treated as trusted, all other pull requests from fork repositories
            will be treated as untrusted.
            Note that if credentials used by Jenkins for scanning the repository does not have permission to
            query the list of collaborators to the origin repository then only the origin account will be treated
            as trusted - i.e. this will fall back to Nobody.
            NOTE: all collaborators are trusted, even if they are only members of a team with read permission.
        
        Everyone
        
            All pull requests from forks will be treated as trusted. NOTE: this option can be dangerous
            if used on a public repository hosted on GitHub.
        
        From users with Admin or Write permission
        
            Pull requests forks will be treated as trusted if and only if the fork owner has either Admin or Write
            permissions on the origin repository.
            This is the recommended policy.
            Note that this strategy requires the
            Review
            a user's permission level API, as a result on GitHub Enterprise Server versions before 2.12 this
            is the same as trusting Nobody.

Nested choice of objects

gitHubTrustContributors

gitHubTrustEveryone

gitHubTrustNobody

gitHubTrustPermissions

browser

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

lfs

gitTool

gitTool: Type:String

gitHubIgnoreDraftPullRequestFilter

ignoreOnPush

localBranch

multiBranchProjectDisplayNaming


    Some branch source plugins provide additional information about discovered branches like a title or subject of merge or change requests.

    With this trait, that additional information can be used for the job display names.

    Note: Job display name changes do not trigger builds.

displayNamingStrategy


  The different strategies:
  
    
      
        Job display name with fallback to name:
        

        Uses the branch source plugin's display name for the PR instead of the raw name
        

        Value for configuration-as-code: OBJECT_DISPLAY_NAME
      
    
    
      
        Name and, if available, display name:
        

        Joins the raw name and the branch source plugin's display name
        

        Value for configuration-as-code: RAW_AND_OBJECT_DISPLAY_NAME
      
    
    
      
        Simple name:
        

        Just the raw name
        

        Value for configuration-as-code: RAW

Values:

OBJECT_DISPLAY_NAME

RAW_AND_OBJECT_DISPLAY_NAME

RAW

gitHubPullRequestDiscovery


    Discovers pull requests where the origin repository is the same as the target repository.

strategyId


    Determines how pull requests are discovered:
    
        Merging the pull request with the current target branch revision
        Discover each pull request once with the discovered revision corresponding to the result of merging with the
            current revision of the target branch.
            Note that pushes to the target branch will result in new pull request builds.
        
        The current pull request revision
        Discover each pull request once with the discovered revision corresponding to the pull request head revision
            without merging.
        
        Both the current pull request revision and the pull request merged with the current target branch revision
        Discover each pull request twice. The first discovered revision corresponds to the result of merging with
            the current revision of the target branch in each scan. The second parallel discovered revision corresponds
            to the pull request head revision without merging.

Type:int

pruneStaleBranch

pruneStaleTag

refSpecs

templates

Array/List:

Nested object

value: A ref spec to fetch. Any occurrences of @{remote} will be replaced by the remote name (which defaults to origin) before use.
Type:String

headRegexFilter

regex: A Java regular expression to restrict the names. Names that do not match the supplied regular expression will be ignored. NOTE: this filter will be applied to all branch like things, including change requests
Type:String

remoteName

remoteName: Type:String

gitHubSshCheckout


    By default the discovered branches / pull requests will all use the same username / password credentials
    that were used for discovery when checking out sources. This means that the checkout will be using the
    https:// protocol for the Git repository.
    
        This behaviour allows you to select the SSH private key to be used for checking out sources, which will
        consequently force the checkout to use the ssh:// protocol.

credentialsId: Credentials used to check out sources. Must be a SSH key based credential.
Type:String

sparseCheckoutPaths

extension

: Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository). Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths
Array/List:
Nested object
path
Type:String

submoduleOption

extension

: depth (optional)
Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.

Type:int
disableSubmodules (optional)
By disabling support for submodules you can still keep using basic git plugin functionality and just have Jenkins to ignore submodules completely as if they didn't exist.

Type:boolean
parentCredentials (optional)
Use credentials from the default remote of the parent project.

Type:boolean
recursiveSubmodules (optional)
Retrieve all submodules recursively (uses '--recursive' option which requires git>=1.6.5)

Type:boolean
reference (optional)
Specify a folder containing a repository that will be used by Git as a reference during clone operations.
This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

git init --bare git remote add SubProject1 https://gitrepo.com/subproject1 git remote add SubProject2 https://gitrepo.com/subproject2 git fetch --all

Type:String
shallow (optional)
Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.

Type:boolean
threads (optional)
Specify the number of threads that will be used to update submodules.
If unspecified, the command line git default thread count is used.

Type:int
timeout (optional)
Specify a timeout (in minutes) for submodules operations.
This option overrides the default timeout of 10 minutes.
You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int
trackingSubmodules (optional)
Retrieve the tip of the configured branch in .gitmodules (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

userIdentity

extension

Nested object

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

headWildcardFilter

includes: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release* NOTE: this filter will be applied to all branch like things, including change requests
Type:String
excludes: Space-separated list of name patterns to ignore even if matched by the includes list. For example: release alpha-* beta-* NOTE: this filter will be applied to all branch like things, including change requests
Type:String

$class: 'WipeWorkspaceTrait'

gitBranchDiscovery


    Discovers branches on the repository.

gitTagDiscovery


    Discovers tags on the repository.

gitHubBranchDiscovery


    Discovers branches on the repository.

strategyId


    Determines which branches are discovered.
    
        Exclude branches that are also filed as PRs
        
            If you are discovering origin pull requests, you may not want to also build the source branches
            for those pull requests.
        
        Only branches that are also filed as PRs
        
            Similar to discovering origin pull requests, but discovers the branch rather than the pull request. 
            This means env.GIT_BRANCH will be set to the branch name rather than PR-#.
            Also, status notifications for these builds will only be applied to the commit and not to the pull request.
        
        All branches
        
            Ignores whether the branch is also filed as a pull request and instead discovers all branches on the
            origin repository.

Type:int

gitHubTagDiscovery


    Discovers tags on the repository.

fromScm

name


    The name of the SCM head/trunk/branch/tag that this source provides.

Type:String

scm

Nested choice of objects

scmGit


  
  The git plugin provides fundamental git operations for Jenkins projects.
  It can poll, fetch, checkout, and merge contents of git repositories.
  

  
  The scmGit parameter of the git plugin is used with the Pipeline SCM checkout step to checkout git repositories into Pipeline workspaces.
  The Pipeline Syntax Snippet Generator guides the user to select git plugin checkout options and provides online help for each of the options.
  


    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    Examples of the checkout step include:
    

      Checkout step with defaults
      Checkout step with https and a specific branch
      Checkout step with ssh and a private key credential
      Checkout step with https and changelog disabled
      Checkout step with git protocol and polling disabled
    
    See the argument descriptions for more details.
    

    
    The scmGit parameter of the checkout step provides access to all the Pipeline capabilities provided by the git plugin:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    

    
    NOTE: The checkout step with the scmGit parameter is the preferred SCM checkout method.
    For simpler cases that do not require all the capabilities of the git plugin, the git step can also be used.
    
    Use the Pipeline Snippet Generator to generate a sample pipeline script for the checkout step.
    
    
    The checkout step with the scmGit parameter can be used in many cases where the git step cannot be used.
    Refer to the git plugin documentation for detailed descriptions of options available to the checkout step.
    For example, the checkout step supports:
    

      SHA-1 checkout
      Tag checkout
      Submodule checkout
      Sparse checkout
      Large file checkout (LFS)
      Reference repositories
      Branch merges
      Repository tagging
      Custom refspecs
      Timeout configuration
      Changelog calculation against a non-default reference
      Stale branch pruning
    
    

    

    Example: Checkout step with defaults
    
    Checkout from the git plugin source repository using https protocol, no credentials, and the master branch.
    
The Pipeline Snippet Generator generates this example:
checkout scmGit(userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/git-plugin' ]
                ])

    

    Example: Checkout step with https and a specific branch
    
    Checkout from the Jenkins source repository using https protocol, no credentials, and a specific branch (stable-2.289).
    
    The Pipeline Snippet Generator generates this example:
checkout scmGit(branches: [[name: 'stable-2.289']],
                userRemoteConfigs: [
                    [ url: 'https://github.com/jenkinsci/jenkins.git' ]
                ])

    

    Example: Checkout step with ssh and a private key credential
    
    Checkout from the git client plugin source repository using ssh protocol, private key credentials, and the master branch.
    The credential must be a private key credential if the remote git repository is accessed with the ssh protocol.
    The credential must be a username / password credential if the remote git repository is accessed with http or https protocol.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ credentialsId: 'my-private-key-credential-id',
                           url: 'git@github.com:jenkinsci/git-client-plugin.git' ]
                     ])

    

    Example: Checkout step with https and changelog disabled
    
    Checkout from the Jenkins source repository using https protocol, no credentials, the master branch, and changelog calculation disabled.
    If changelog is false, then the changelog will not be computed for this job.
    If changelog is true or is not set, then the changelog will be computed.
    See the workflow scm step documentation for more changelog details.
    
The Pipeline Snippet Generator generates this example:
checkout changelog: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'https://github.com/jenkinsci/credentials-plugin' ]
                     ])

    

    Example: Checkout step with git protocol and polling disabled
    
    Checkout from the command line git repository using git protocol, no credentials, the master branch, and no polling for changes.
    If poll is false, then the remote repository will not be polled for changes.
    If poll is true or is not set, then the remote repository will be polled for changes.
    See the workflow scm step documentation for more polling details.
    
The Pipeline Snippet Generator generates this example:
checkout poll: false,
         scm: scmGit(userRemoteConfigs: [
                         [ url: 'git://git.kernel.org/pub/scm/git/git.git' ]
                     ])

    

    

    Argument Descriptions

userRemoteConfigs


  Specify the repository to track. This can be a URL or a local file path.
  Note that for super-projects (repositories with submodules), only a local file
  path or a complete URL is valid.  The following are examples of valid git URLs.
  
    ssh://git@github.com/github/git.git
    git@github.com:github/git.git (short notation for ssh protocol)
    ssh://user@other.host.com/~/repos/R.git (to access the repos/R.git
    repository in the user's home directory)
    https://github.com/github/git.git
  
  

  If the repository is a super-project, the
  location from which to clone submodules is dependent on whether the repository
  is bare or non-bare (i.e. has a working directory).
  
    If the super-project is bare, the location of the submodules will be
    taken from .gitmodules.
    If the super-project is not bare, it is assumed that the
    repository has each of its submodules cloned and checked out appropriately.
    Thus, the submodules will be taken directly from a path like
    ${SUPER_PROJECT_URL}/${SUBMODULE}, rather than relying on
    information from .gitmodules.
  

  For a local URL/path to a super-project,
  git rev-parse --is-bare-repository
  is used to detect whether the super-project is bare or not.
  

  For a remote URL to a super-project, the ending of the URL determines whether
  a bare or non-bare repository is assumed:
  
    If the remote URL ends with .git, a non-bare repository is
    assumed.
    If the remote URL does NOT end with .git, a bare
    repository is assumed.

Array/List:

Nested object

url: Specify the URL or path of the git repository. This uses the same syntax as your git clone command.
Type:String
name: ID of the repository, such as origin, to uniquely identify this repository among other remote repositories. This is the same "name" that you use in your git remote command. If left empty, Jenkins will generate unique names for you. You normally want to specify this when you have multiple remote repositories.
Type:String
refspec: A refspec controls the remote refs to be retrieved and how they map to local refs. If left blank, it will default to the normal behaviour of git fetch, which retrieves all the branch heads as remotes/REPOSITORYNAME/BRANCHNAME. This default behaviour is OK for most cases. In other words, the default refspec is "+refs/heads/*:refs/remotes/REPOSITORYNAME/*" where REPOSITORYNAME is the value you specify in the above "name of repository" textbox. When do you want to modify this value? A good example is when you want to just retrieve one branch. For example, +refs/heads/master:refs/remotes/origin/master would only retrieve the master branch and nothing else. The plugin uses a default refspec for its initial fetch, unless the "Advanced Clone Option" is set to honor refspec. This keeps compatibility with previous behavior, and allows the job definition to decide if the refspec should be honored on initial clone. Multiple refspecs can be entered by separating them with a space character. +refs/heads/master:refs/remotes/origin/master +refs/heads/develop:refs/remotes/origin/develop retrieves the master branch and the develop branch and nothing else. See the refspec definition in Git user manual for more details.
Type:String
credentialsId: Credential used to check out sources.
Type:String

branches


  List of branches to build.
  Jenkins jobs are most effective when each job builds only a single branch.
  When a single job builds multiple branches, the changelog comparisons between branches often show no changes or incorrect changes.

Array/List:

Nested object

name


  Specify the branches if you'd like to track a specific branch in a repository.
  If left blank, all branches will be examined for changes and built.

  The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch
  is unambiguous.

  If your branch name has a / in it make sure to use the full reference above. When not presented
  with a full path the plugin will only use the part of the string right of the last slash.
  Meaning foo/bar will actually match bar.

  If you use a wildcard branch specifier, with a slash (e.g. release/),
  you'll need to specify the origin repository in the branch names to
  make sure changes are picked up. So e.g. origin/release/

  Possible options:
    

       <branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one. Better use refs/heads/<branchName>.

           E.g. master, feature1, ...
      
       refs/heads/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/heads/master, refs/heads/feature1/master, ...
      
       <remoteRepoName>/<branchName>

           Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily
           the expected one.

           Better use refs/heads/<branchName>.

           E.g. origin/master
      
       remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. remotes/origin/master
      
       refs/remotes/<remoteRepoName>/<branchName>

           Tracks/checks out the specified branch.

           E.g. refs/remotes/origin/master
      
       <tagName>

           This does not work since the tag will not be recognized as tag.

           Use refs/tags/<tagName> instead.

           E.g. git-2.3.0
      
       refs/tags/<tagName>

           Tracks/checks out the specified tag.

           E.g. refs/tags/git-2.3.0
      
       <commitId>

           Checks out the specified commit.

           E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
      
       ${ENV_VARIABLE}

           It is also possible to use environment variables. In this case the variables are evaluated and the
           result is used as described above.

           E.g. ${TREEISH}, refs/tags/${TAGNAME}, ...
      
       <Wildcards>

           The syntax is of the form: REPOSITORYNAME/BRANCH.
           In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard,
           and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would
           match origin/branches-foo but not origin/branches/foo, while origin/branches** would
           match both origin/branches-foo and origin/branches/foo.
      
       :<regular expression>

           The syntax is of the form: :regexp.
           Regular expression syntax in branches to build will only
           build those branches whose names match the regular
           expression.

           Examples:

            
                :^(?!(origin/prefix)).*
                  
                    matches: origin or origin/master or origin/feature
                    does not match: origin/prefix or origin/prefix_123 or origin/prefix-abc
                  
                
                :origin/release-\d{8}
                  
                    matches: origin/release-20150101
                    does not match: origin/release-2015010 or origin/release-201501011 or origin/release-20150101-something
                  
                
                :^(?!origin/master$|origin/develop$).*
                  
                    matches: origin/branch1 or origin/branch-2 or origin/master123 or origin/develop-123
                    does not match: origin/master or origin/develop

Type:String

browser


  Defines the repository browser that displays changes detected by the git plugin.

Nested choice of objects

assembla

repoUrl: Specify the root URL serving this repository (such as https://www.assembla.com/code/PROJECT/git/).
Type:String

bitbucketServer

repoUrl: Specify the Bitbucket Server root URL for this repository (such as https://bitbucket:7990/OWNER/REPO/).
Type:String

bitbucket

repoUrl: Specify the root URL serving this repository (such as https://bitbucket.org/OWNER/REPO/).
Type:String

cgit

repoUrl: Specify the root URL serving this repository (such as https://cgit.example.com:port/group/REPO/).
Type:String

fisheye

repoUrl: Specify the URL of this repository in FishEye (such as https://fisheye.example.com/browse/project/).
Type:String

gitblit

repoUrl: Specify the root URL serving this repository.
Type:String
projectName: Specify the name of the project in GitBlit.
Type:String

gitLab

repoUrl: Specify the root URL serving this repository (such as https://gitlab.com/username/repository/).
Type:String

version (optional): Specify the major and minor version of GitLab you use (such as 9.1). If you don't specify a version, a modern version of GitLab (>= 8.0) is assumed.
Type:String

gitList

repoUrl: Specify the root URL serving this repository (such as https://gitlist.example.com/repo/).
Type:String

gitWeb

repoUrl: Specify the root URL serving this repository (such as https://github.com/jenkinsci/jenkins.git).
Type:String

github

repoUrl: Specify the HTTP URL for this repository's GitHub page (such as https://github.com/jquery/jquery).
Type:String

gitiles

repoUrl: Specify the root URL serving this repository (such as https://gwt.googlesource.com/gwt/).
Type:String

$class: 'GitoriousWeb'

repoUrl: Specify the root URL serving this repository (such as https://gitorious.org/gitorious/mainline).
Type:String

gogs

repoUrl: Specify the root URL serving this repository (such as https://gogs.example.com/username/some-repo-url.git).
Type:String

kiln

repoUrl: Specify the root URL serving this repository (such as https://khanacademy.kilnhg.com/Code/Website/Group/webapp).
Type:String

phabricator

repoUrl: Specify the phabricator instance root URL (such as https://phabricator.example.com).
Type:String
repo: Specify the repository name in phabricator (such as the foo part of phabricator.example.com/diffusion/foo/browse).
Type:String

redmine

repoUrl: Specify the root URL serving this repository (such as https://redmine.example.com/PATH/projects/PROJECT/repository).
Type:String

rhodeCode

repoUrl: Specify the HTTP URL for this repository's RhodeCode page (such as https://rhodecode.example.com/projects/PROJECT/repos/REPO/).
Type:String

$class: 'Stash'

repoUrl: Specify the HTTP URL for this repository's Stash page (such as https://stash.example.com/projects/PROJECT/repos/REPO/).
Type:String

teamFoundation

repoUrl: Either the name of the remote whose URL should be used, or the URL of this module in TFS (such as https://tfs.example.com/tfs/PROJECT/_git/REPO/). If empty (default), the URL of the "origin" repository is used. If TFS is also used as the repository server, this can usually be left blank.
Type:String

viewgit

repoUrl: Specify the root URL serving this repository (such as https://git.example.com/viewgit/).
Type:String
projectName: Specify the name of the project in ViewGit (e.g. scripts, scuttle etc. from https://code.fealdia.org/viewgit/).
Type:String

gitTool

Name of the git tool to be used for this job. Git tool names are defined in "Global Tool Configuration".

Type:String

extensions


  
  Extensions add new behavior or modify existing plugin behavior for different uses.
  Extensions help users more precisely tune plugin behavior to meet their needs.
  
  
  Extensions include:
    

      
        Clone extensions modify the git operations that retrieve remote changes into the agent workspace.
        The extensions can adjust the amount of history retrieved, how long the retrieval is allowed to run, and other retrieval details.
      
      
        Checkout extensions modify the git operations that place files in the workspace from the git repository on the agent.
        The extensions can adjust the maximum duration of the checkout operation, the use and behavior of git submodules, the location of the workspace on the disc, and more.
      
      
        Changelog extensions adapt the source code difference calculations for different cases.
      
      
        Tagging extensions allow the plugin to apply tags in the current workspace.
      
      
        Build initiation extensions control the conditions that start a build.
        They can ignore notifications of a change or force a deeper evaluation of the commits when polling.
      
      
        Merge extensions can optionally merge changes from other branches into the current branch of the agent workspace.
        They control the source branch for the merge and the options applied to the merge.

Array/List:

Nested choice of objects

authorInChangelog


  The default behavior is to use the Git commit's "Committer" value in Jenkins' build changesets.
  If this option is selected, the Git commit's "Author" value would be used instead.

$class: 'BuildChooserSetting'


    When you are interested in using a job to build multiple heads (most typically multiple branches),
    you can choose how Jenkins choose what branches to build in what order.

    
    This extension point in Jenkins is used by many other plugins to control the job to build
    specific commits. When you activate those plugins, you may see them installing a custom strategy
    here.

buildChooser

Nested choice of objects

$class: 'AncestryBuildChooser'

maximumAgeInDays: Type:int
ancestorCommitSha1: Type:String

$class: 'DefaultBuildChooser'

$class: 'InverseBuildChooser'

buildSingleRevisionOnly


    Disable scheduling for multiple candidate revisions.

    If we have 3 branches:

    ----A--.---.--- B

             \-----C

    jenkins would try to build (B) and (C).

    This behaviour disables this and only builds one of them.

    It is helpful to reduce the load of the Jenkins infrastructure when the
    SCM system like Bitbucket or GitHub should decide what commits to build.

changelogToBranch


    This method calculates the changelog against the specified branch.

options

: compareRemote
Name of the repository, such as origin, that contains the branch you specify below.
Type:String
compareTarget
The name of the branch within the named repository to compare against.
Type:String

checkoutOption

timeout: Specify a timeout (in minutes) for checkout. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

cleanBeforeCheckout


  Clean up the workspace before every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cleanAfterCheckout


  Clean up the workspace after every checkout by deleting all untracked files and directories,
  including those which are specified in .gitignore.
  It also resets all tracked files to their versioned state.
  This ensures that the workspace is
  in the same state as if you cloned and checked out in a brand-new empty directory, and ensures
  that your build is not affected by the files generated by the previous build.

deleteUntrackedNestedRepositories (optional): Deletes untracked submodules and any other subdirectories which contain .git directories.
Type:boolean

cloneOption

shallow: Perform shallow clone, so that git will not download the history of the project, saving time and disk space when you just want to access the latest version of a repository.
Type:boolean
noTags: Deselect this to perform a clone without tags, saving time and disk space when you just want to access what is specified by the refspec.
Type:boolean
reference: Specify a folder containing a repository that will be used by Git as a reference during clone operations. This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.
Type:String
timeout: Specify a timeout (in minutes) for clone and fetch operations. This option overrides the default timeout of 10 minutes. You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286). Note that property should be set on both controller and agent to have effect (see JENKINS-22547).
Type:int

depth (optional): Set shallow clone depth, so that git will only download recent history of the project, saving time and disk space when you just want to access the latest commits of a repository.
Type:int
honorRefspec (optional): Perform initial clone using the refspec defined for the repository. This can save time, data transfer and disk space when you only need to access the references specified by the refspec.
Type:boolean

$class: 'DisableRemotePoll'


       Git plugin uses git ls-remote polling mechanism by default when configured with a single branch (no wildcards!).
       This compares the most recently built commit SHA with the remote branch without cloning a local copy of the repo.


       If this option is selected, polling will require a workspace and might trigger unwanted builds (see JENKINS-10131).

firstBuildChangelog


  First builds will populate the changelog with the latest commit, if any, to allow Pipelines to check and test for file changes.
  By default, no changelog is generated for the first build because the first build has no predecessor build for comparison.
  When the first build changelog option is enabled, the most recent commit on the branch will be used as the changelog of the first build.

makeChangelog (optional): Type:boolean

lfs


	Enable git large file support for the workspace by pulling large files after the checkout completes.
	Requires that the controller and each agent performing an LFS checkout have installed `git lfs`.

$class: 'IgnoreNotifyCommit'


    If checked, this repository will be ignored when the notifyCommit-URL is accessed regardless of if the repository
    matches or not.

localBranch


  If given, checkout the revision to build as HEAD on this branch.

  If selected, and its value is an empty string or "**", then the branch
  name is computed from the remote branch without the origin.  In that
  case, a remote branch origin/master will be checked out to a local
  branch named master, and a remote branch origin/develop/new-feature
  will be checked out to a local branch named develop/newfeature.

  Please note that this has not been tested with submodules.

localBranch: Type:String

$class: 'MessageExclusion'

excludedMessage


    If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed with message matched to
    Pattern when determining
    if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build,
    assuming the build server commits the change with a distinct message.
    Exclusion uses Pattern
    matching
    

  
.*\[maven-release-plugin\].*
    The example above illustrates that if only revisions with "[maven-release-plugin]" message in first comment line
    have been committed to the SCM a build will not occur.
    
    You can create more complex patterns using embedded flag expressions.
   
(?s).*FOO.*
     This example will search FOO message in all comment lines.

Type:String

$class: 'PathRestriction'


 If set, and Jenkins is set to poll for changes, Jenkins will pay attention to included and/or excluded files and/or
  folders when determining if a build needs to be triggered.

 Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

includedRegions


  Each inclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  An empty list implies that everything is included.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that a build will only occur, if html/jpeg/gif files
  have been committed to the SCM. Exclusions take precedence over inclusions, if there is
  an overlap between included and excluded regions.

Type:String

excludedRegions


  Each exclusion uses java regular expression pattern matching,
    and must be separated by a new line.
  
  
    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  
  The example above illustrates that if only html/jpeg/gif files have been committed to
  the SCM a build will not occur.

Type:String

perBuildTag


  Create a tag in the workspace for every build to unambiguously mark the commit that was built.
  You can combine this with Git publisher to push the tags to the remote repository.

$class: 'PreBuildMerge'


  These options allow you to perform a merge to a particular branch before building.
  For example, you could specify an integration branch to be built, and to merge to master.
  In this scenario, on every change of integration, Jenkins will perform a merge with the master branch,
  and try to perform a build if the merge is successful.
  It then may push the merge back to the remote repository if the Git Push post-build action is selected.

options

Nested object

mergeTarget: The name of the branch within the named repository to merge to, such as master.
Type:String

fastForwardMode (optional): Merge fast-forward mode selection. The default, --ff, gracefully falls back to a merge commit when required. For more information, see the Git Merge Documentation
Values:
FF
FF_ONLY
NO_FF
mergeRemote (optional): Name of the repository, such as origin, that contains the branch you specify below. If left blank, it'll default to the name of the first repository configured above.
Type:String
mergeStrategy (optional): Merge strategy selection. This feature is not fully implemented in JGIT.
Values:
DEFAULT
RESOLVE
RECURSIVE
OCTOPUS
OURS
SUBTREE
RECURSIVE_THEIRS

pruneStaleBranch


  Run "git remote prune" for each remote, to prune obsolete local branches.

pruneTags

pruneTags: Type:boolean

$class: 'RelativeTargetDirectory'

relativeTargetDir: Specify a local directory (relative to the workspace root) where the Git repository will be checked out. If left empty, the workspace root itself will be used. This extension should not be used in Jenkins Pipeline (either declarative or scripted). Jenkins Pipeline already provides standard techniques for checkout to a subdirectory. Use ws and dir in Jenkins Pipeline rather than this extension.
Type:String

$class: 'ScmName'


  Unique name for this SCM. Needed when using Git within the Multi SCM plugin.

name: Type:String

sparseCheckout


  
    Specify the paths that you'd like to sparse checkout. This may be used for saving space (Think about a reference repository).
    Be sure to use a recent version of Git, at least above 1.7.10

sparseCheckoutPaths

Array/List:

Nested object

path: Type:String

submodule

depth (optional)


  Set shallow clone depth, so that git will only download recent history of the project,
  saving time and disk space when you just want to access the latest commits of a repository.

Type:int

disableSubmodules (optional)


    By disabling support for submodules you can still keep using basic
    git plugin functionality and just have Jenkins to ignore submodules
    completely as if they didn't exist.

Type:boolean

parentCredentials (optional)


  Use credentials from the default remote of the parent project.

Type:boolean

recursiveSubmodules (optional)


  Retrieve all submodules recursively

  (uses '--recursive' option which requires git>=1.6.5)

Type:boolean

reference (optional)


  Specify a folder containing a repository that will be used by Git as a reference during clone operations.

  This option will be ignored if the folder is not available on the controller or agent where the clone is being executed.

  To prepare a reference folder with multiple subprojects, create a bare git repository and add all the remote urls then perform a fetch:

    git init --bare
  git remote add SubProject1 https://gitrepo.com/subproject1
  git remote add SubProject2 https://gitrepo.com/subproject2
  git fetch --all

Type:String

shallow (optional)


  Perform shallow clone, so that git will not download the history of the project,
  saving time and disk space when you just want to access the latest version of a repository.

Type:boolean

threads (optional)


  Specify the number of threads that will be used to update submodules.

  If unspecified, the command line git default thread count is used.

Type:int

timeout (optional)


  Specify a timeout (in minutes) for submodules operations.

  This option overrides the default timeout of 10 minutes. 

  You can change the global git timeout via the property org.jenkinsci.plugins.gitclient.Git.timeOut (see JENKINS-11286).
  Note that property should be set on both controller and agent to have effect (see JENKINS-22547).

Type:int

trackingSubmodules (optional)


   Retrieve the tip of the configured branch in .gitmodules

   (Uses '--remote' option which requires git>=1.8.2)

Type:boolean

$class: 'UserExclusion'

excludedUsers


  If set, and Jenkins is set to poll for changes, Jenkins will ignore any revisions committed by users in this list when determining if a build needs to be triggered. This can be used to exclude commits done by the build itself from triggering another build, assuming the build server commits the change with a distinct SCM user.
  
  Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.
  
Each exclusion uses exact string comparison and must be separated by a new line.
      User names are only excluded if they exactly match one of the names in this list.
  

  
auto_build_user
  The example above illustrates that if only revisions by "auto_build_user" have been committed to the SCM a build will not occur.

Type:String

$class: 'UserIdentity'

name: If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String
email: If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.
Type:String

$class: 'WipeWorkspace'


  Delete the contents of the workspace before building, ensuring a fully fresh workspace.

doGenerateSubmoduleConfigurations (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value and always uses false as its value.

Type:boolean

submoduleCfg (optional)

Removed facility that was intended to test combinations of git submodule versions. Removed in git plugin 4.6.0. Ignores the user provided value(s) and always uses empty values.

Array/List:

Nested object

submoduleName: Removed in git plugin 4.6.0.
Type:String
branches: Removed in git plugin 4.6.0.
Array/List:
Type:String

none

id (optional): Type:String

targets



    The branch names to try and resolve from the source, in order of preference.

Array/List:

Type:String

ignoreErrors (optional): When selected, the step will return null in the event that no matching branch can be resolved.
Type:boolean

retry: Retry the body up to N times


    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.

count: Type:int

conditions (optional)


    Conditions under which the block should be retried.
    If none match, the block will fail.
    If there are no specified conditions,
    the block will always be retried except in case of user aborts.

Array/List:

Nested choice of objects

agent


    Detects that a node block, or certain steps inside it such as sh,
    failed for reasons which are likely due to infrastructure rather than the behavior of the build.
    If the connection to an agent is broken or the agent is removed from the list of executors while in use
    (typically in response to the disappearance of underlying cloud resources),
    this condition will allow retry to allocate a fresh agent and try the whole block again.

nonresumable


    The Jenkins controller was restarted while the build was running a step which cannot be resumed.
    Some steps like sh or input are written to survive a Jenkins restart
    and simply pick up where they left off when the build resumes.
    Others like checkout or junit normally complete promptly but cannot tolerate a restart.
    In case one of these steps happened to be in progress when Jenkins shut down,
    the resumed build will throw an error;
    using this condition with retry allows the step (or the whole enclosing node block) to be rerun.

script: Run arbitrary Pipeline script

sh: Shell Script

script: 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).
Type:String

encoding (optional): 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'
Type:String
label (optional): 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.
Type:String
returnStatus (optional): 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.
Type:boolean
returnStdout (optional): 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.
Type:boolean

sleep: Sleep


    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.

time: The length of time for which the step will sleep.
Type:int

unit (optional): The unit for the time parameter. Defaults to 'SECONDS' if not specified.
Values:
NANOSECONDS
MICROSECONDS
MILLISECONDS
SECONDS
MINUTES
HOURS
DAYS

stage: Stage


    Creates a labeled block.

name: Type:String

concurrency (optional): Type:int

stash: Stash some files to be used later in the build


    Saves a set of files for later use on any node/workspace in the same Pipeline run.
    By default, stashed files are discarded at the end of a pipeline run.
    Other plugins may change this behavior to preserve stashes for longer.
    For example, Declarative Pipeline includes a preserveStashes() option
    to allow stashes from a run to be retained and used if that run is restarted. 
    

    Stashes from one Pipeline run are not available in other runs, other Pipelines, or other jobs.
    If you want to persist artifacts for use outside of a single run, consider using 
    
    archiveArtifacts instead.
    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
    resources on the controller, particularly CPU time.
    There's not a hard stash size limit, but between 5-100 MB you should probably consider alternatives.
    If you use the Artifact Manager on S3 plugin, or another plugin with a remote atifact manager,
    you can use this step without affecting controller performance
    since stashes will be sent directly to S3 from the agent (and similarly for unstash).

name: Name of a stash. Should be a simple identifier akin to a job name.
Type:String

allowEmpty (optional): Create stash even if no files are included. If false (default), an error is raised when the stash does not contain files.
Type:boolean
excludes (optional): Optional set of Ant-style exclude patterns. Use a comma separated list to add more than one expression. If blank, no files will be excluded.
Type:String
includes (optional): Optional set of Ant-style include patterns. Use a comma separated list to add more than one expression. If blank, treated like **: all files. The current working directory is the base directory for the saved files, which will later be restored in the same relative locations, so if you want to use a subdirectory wrap this in dir.
Type:String
useDefaultExcludes (optional): If selected, use the default excludes from Ant - see here for the list. Defaults to true.
Type:boolean

step: General Build Step


    
    This is a special step that allows to call builders or post-build actions (as in freestyle or similar projects), in general "build steps".
    Just select the build step to call from the dropdown list and configure it as needed.
    
    
    Note that only Pipeline-compatible steps will be shown in the list.

delegate

Nested choice of objects

archiveArtifacts


  Archives the build artifacts (for example, distribution zip files or jar
  files) so that they can be downloaded later. Archived files will be accessible
  from the Jenkins webpage.
  

  Normally, Jenkins keeps artifacts for a build as long as a build log itself is
  kept, but if you don't need old artifacts and would rather save disk space,
  you can do so.





  Note that the Maven job type automatically archives any produced Maven
  artifacts. Any artifacts configured here will be archived on top of that.
  Automatic artifact archiving can be disabled under the advanced Maven options.






  The
  
    Pipeline Snippet Generator
  
  generates this example when all arguments are set to true (some arguments by
  default are true):
  archiveArtifacts artifacts: '**/*.txt',
                   allowEmptyArchive: true,
                   fingerprint: true,
                   onlyIfSuccessful: true

artifacts


  You can use wildcards like 'module/dist/**/*.zip'. See
  
    the includes attribute of Ant fileset
  
  for the exact format -- except that
  ","
  (
  comma
  ) is the only supported separator. The base directory is
  the workspace
  . You can only archive files that are located in your workspace.






  Here are some examples of usage for pipeline:
  
    
      How to archive multiple artifacts from a specific folder:

      archiveArtifacts artifacts: 'target/*.jar'
    
    


    
      How to archive multiple artifacts with different patterns:
      archiveArtifacts artifacts: 'target/*.jar, target/*.war'
    
    

    
      How to archive multiple nested artifacts:
      archiveArtifacts artifacts: '**/*.jar'

Type:String

allowEmptyArchive (optional): Normally, a build fails if archiving returns zero artifacts. This option allows the archiving process to return nothing without failing the build. Instead, the build will simply throw a warning.
Type:boolean
caseSensitive (optional): Artifact archiver uses Ant org.apache.tools.ant.DirectoryScanner which by default is case sensitive. For instance, if the job produces *.hpi files, pattern "**/*.HPI" will fail to find them. This option can be used to disable case sensitivity. When it's unchecked, pattern "**/*.HPI" will match any *.hpi files, or pattern "**/cAsEsEnSiTiVe.jar" will match a file called caseSensitive.jar.
Type:boolean
defaultExcludes (optional): Type:boolean
excludes (optional): Optionally specify the 'excludes' pattern, such as "foo/bar/**/*". Use "," to set a list of patterns. A file that matches this mask will not be archived even if it matches the mask specified in 'files to archive' section.
Type:String
fingerprint (optional): Type:boolean
followSymlinks (optional): By disabling this option all symbolic links found in the workspace will be ignored.
Type:boolean
onlyIfSuccessful (optional): Type:boolean

fingerprint


  Jenkins can record the 'fingerprint' of files (most often jar files) to keep
  track of where/when those files are produced and used. When you have
  inter-dependent projects on Jenkins, this allows you to quickly find out
  answers to questions like:

  
    
      I have
      foo.jar
      on my HDD but which build number of FOO did it come from?
    
    
      My BAR project depends on
      foo.jar
      from the FOO project.
    
    
      
        
          Which build of
          foo.jar
          is used in BAR #51?
        
        
          Which build of BAR contains my bug fix to
          foo.jar
          #32?
        
      
    
  

  
    To use this feature, all of the involved projects (not just the project in
    which a file is produced, but also the projects in which the file is used)
    need to use this and record fingerprints.
  

  
    See
    this document
    for more details.

targets: Can use wildcards like module/dist/**/*.zip (see the @includes of Ant fileset for the exact format). The base directory is the workspace .
Type:String

caseSensitive (optional): Fingerprinter uses Ant org.apache.tools.ant.DirectoryScanner which by default is case sensitive. For instance, if the job produces *.hpi files, pattern "**/*.HPI" will fail to find them. This option can be used to disable case sensitivity. When it's unchecked, pattern "**/*.HPI" will match any *.hpi files, or pattern "**/cAsEsEnSiTiVe.jar" will match a file called caseSensitive.jar.
Type:boolean
defaultExcludes (optional): Type:boolean
excludes (optional): Optionally specify the 'excludes' pattern, such as "foo/bar/**/*". Use "," to set a list of patterns. A file that matches this mask will not be fingerprinted even if it matches the mask specified in 'files to fingerprint' section.
Type:String

$class: 'GitHubCommitNotifier'


    This notifier will set GH commit status.
    This step is DEPRECATED and will be migrated to new step in one of the next major plugin releases. 

    Please refer to new universal step.

resultOnFailure: Type:String

statusMessage (optional)

Nested object

content: Message content that will be expanded using core variable expansion i.e. ${WORKSPACE} and Token Macro Plugin tokens.
Type:String

$class: 'GitHubCommitStatusSetter'


    Using GitHub status api sets status of the commit.

commitShaSource (optional)

Nested choice of objects

$class: 'BuildDataRevisionShaSource'


    Uses data-action (located at ${build.url}/git/) to determine actual SHA.

$class: 'ManuallyEnteredShaSource'


    Allows to define commit SHA manually.

sha: Allows env vars and token macro.
Type:String

contextSource (optional)

Nested choice of objects

$class: 'DefaultCommitContextSource'


    Uses display name property defined in "GitHub project property" with fallback to job name.

$class: 'ManuallyEnteredCommitContextSource'


    You can define context name manually.

context: Allows env vars and token macros.
Type:String

errorHandlers (optional)

Array/List:

Nested choice of objects

$class: 'ChangingBuildStatusErrorHandler'

result: Type:String

$class: 'ShallowAnyErrorHandler'

reposSource (optional)

Nested choice of objects

$class: 'AnyDefinedRepositorySource'


    Any repository provided by the programmatic contributors list.

$class: 'ManuallyEnteredRepositorySource'


    A manually entered repository URL.

url: A GitHub repository URL.
Type:String

statusBackrefSource (optional)

Nested choice of objects

$class: 'BuildRefBackrefSource'


   Points commit status backref back to the producing build page.

$class: 'ManuallyEnteredBackrefSource'


    A manually entered backref URL.

backref: A backref URL. Allows env vars and token macro.
Type:String

statusResultSource (optional)

Nested choice of objects

$class: 'ConditionalStatusResultSource'


    You can define in which cases you want to publish exact state and message for the commit. You can define multiple cases.
    First match (starting from top) wins. If no one matches, PENDING status + warn message will be used.

results

Array/List:

Nested choice of objects

$class: 'AnyBuildResult'

message (optional): Type:String
state (optional): Type:String

$class: 'BetterThanOrEqualBuildResult'

message (optional): Allows env vars and token macro.
Type:String
result (optional): Type:String
state (optional): Type:String

$class: 'DefaultStatusResultSource'


    Writes simple message about build result and duration.

$class: 'GitHubSetCommitStatusBuilder'

contextSource (optional)

Nested choice of objects

$class: 'DefaultCommitContextSource'


    Uses display name property defined in "GitHub project property" with fallback to job name.

$class: 'ManuallyEnteredCommitContextSource'


    You can define context name manually.

context: Allows env vars and token macros.
Type:String

statusMessage (optional)

Nested object

content: Message content that will be expanded using core variable expansion i.e. ${WORKSPACE} and Token Macro Plugin tokens.
Type:String

$class: 'JUnitResultArchiver'


  Jenkins understands the JUnit test report XML format (which is also used by TestNG).
  When this option is configured, Jenkins can provide useful information about test results,
  such as historical test result trends, a web UI for viewing test reports, tracking failures,
  and so on.

  
  To use this feature, first set up your build to run tests, then
  specify the path to JUnit XML files in the
  Ant glob syntax,
  such as **/build/test-reports/*.xml. Be sure not to include any non-report
  files into this pattern. You can specify multiple patterns of files separated by commas.

testResults: Type:String

allowEmptyResults (optional)


    If checked, the default behavior of failing a build on missing test result files
    or empty test results is changed to not affect the status of the build.
    Please note that this setting make it harder to spot misconfigured jobs or
    build failures where the test tool does not exit with an error code when
    not producing test report files.

Type:boolean

checksName (optional)


    If provided, and publishing checks enabled, the plugin will use this name when publishing results to corresponding
    SCM hosting platforms. If not, a default of "Tests" will be used.

Type:String

healthScaleFactor (optional)


    The amplification factor to apply to test failures when computing the test result contribution to the build health
    score.
    

    The default factor is 1.0
    
        A factor of 0.0 will disable the test result contribution to build health score.
        A factor of 0.1 means that 10% of tests failing will score 99% health
        A factor of 0.5 means that 10% of tests failing will score 95% health
        A factor of 1.0 means that 10% of tests failing will score 90% health
        A factor of 2.0 means that 10% of tests failing will score 80% health
        A factor of 2.5 means that 10% of tests failing will score 75% health
        A factor of 5.0 means that 10% of tests failing will score 50% health
        A factor of 10.0 means that 10% of tests failing will score 0% health
    
    The factor is persisted with the build results, so changes will only be reflected in new builds.

Type:double

keepLongStdio (optional)


  Deprecated, use stdioRetention instead.
  
    If checked, any standard output or error from a test suite will be retained
    in the test results after the build completes. (This refers only to additional
    messages printed to console, not to a failure stack trace.) Such output is
    always kept if the test failed, but by default lengthy output from passing
    tests is truncated to save space. Check this option if you need to see every
    log message from even passing tests, but beware that Jenkins's memory consumption
    can substantially increase as a result, even if you never look at the test results!

Type:boolean

keepProperties (optional)

Type:boolean

keepTestNames (optional)

Type:boolean

skipMarkingBuildUnstable (optional)


    If this option is unchecked, then the plugin will mark the build as unstable when it finds at least 1 test failure.
    If this option is checked, then the build will still be successful even if there are test failures reported.

Type:boolean

skipOldReports (optional)

Type:boolean

skipPublishingChecks (optional)


    If this option is unchecked, then the plugin automatically publishes the test results to corresponding SCM hosting platforms.
    For example, if you are using this feature for a GitHub organization project, the warnings will be published to
    GitHub through the Checks API. If this operation slows down your build, or you don't want to publish the warnings to
    SCM platforms, you can use this option to deactivate this feature.

Type:boolean

stdioRetention (optional)


    Controls how standard output or error from a test suite will be retained
    in the test results after the build completes. (This refers only to additional
    messages printed to console, not to a failure stack trace.) Some output is
    always retained for tests, but by default, excessively long output is truncated
    to save disk space. This property can be used to control whether that truncation
    takes place:
    
        If set to 'all', then no truncation will take place and the complete output from
        every test will be stored.
        If set to 'failed', then the complete output from all failed tests will be stored,
        but long output from passing tests will be truncated.
        If set to 'none', then long output from every test will be truncated, regardless
        of whether they passed or failed.
    
    Beware that storing large output can cause Jenkins's memory consumption to
    substantially increase, even if you never look at the test results.

Type:String

testDataPublishers (optional)

Array/List:

Nested choice of objects

$class: 'Mailer'


  If configured, Jenkins will send out an e-mail to the specified recipients
  when a certain important event occurs.

  
    Every failed build triggers a new e-mail.
    
A successful build after a failed (or unstable) build triggers a new e-mail,
        indicating that a crisis is over.
    
An unstable build after a successful build triggers a new e-mail,
        indicating that there's a regression.
    
Unless configured, every unstable build triggers a new e-mail,
        indicating that regression is still there.
  

  For lazy projects where unstable builds are the norm, Uncheck "Send e-mail for every unstable build".

recipients: Type:String
notifyEveryUnstableBuild: Type:boolean
sendToIndividuals: If this option is checked, the notification e-mail will be sent to individuals who have committed changes for the broken build (by assuming that those changes broke the build). If e-mail addresses are also specified in the recipient list, then both the individuals as well as the specified addresses get the notification e-mail. If the recipient list is empty, then only the individuals will receive e-mails.
Type:boolean

cleanWs

cleanWhenAborted (optional)

Type:boolean

cleanWhenFailure (optional)

Type:boolean

cleanWhenNotBuilt (optional)

Type:boolean

cleanWhenSuccess (optional)

Type:boolean

cleanWhenUnstable (optional)

Type:boolean

cleanupMatrixParent (optional)

Type:boolean

deleteDirs (optional)

Type:boolean

disableDeferredWipeout (optional)

Type:boolean

externalDelete (optional)

Type:String

notFailBuild (optional)

Type:boolean

patterns (optional)

Array/List:

Nested object

pattern: Type:String
type: Values:
INCLUDE
EXCLUDE

skipWhenFailed (optional)

Type:boolean

timeout: Enforce time limit


    Executes the code inside the block with a determined time out limit.
    If the time limit is reached, an exception (org.jenkinsci.plugins.workflow.steps.FlowInterruptedException) is thrown, which leads to aborting
    the build (unless it is caught and processed somehow).

time: The length of time for which this step will wait before cancelling the nested block.
Type:int

activity (optional): Timeout after no activity in logs for this block instead of absolute duration. Defaults to false.
Type:boolean
unit (optional): The unit of the time parameter. Defaults to 'MINUTES' if not specified.
Values:
NANOSECONDS
MICROSECONDS
MILLISECONDS
SECONDS
MINUTES
HOURS
DAYS

timestamps: Timestamps

tm: Expand a string containing macros

stringWithMacro: Type:String

tool: Use a tool from a predefined Tool Installation


    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.

name: The name of the tool. The tool name must be pre-configured in Jenkins under Manage Jenkins → Global Tool Configuration.
Type:String

type (optional): Select the type from the available built-in tool providers.
Type:String

unstable: Set stage result to unstable


    Prints a message to the log and sets the overall build result and the stage
    result to UNSTABLE. The message will also be associated with
    the stage result and may be shown in visualizations.

message: A message that will be logged to the console. The message will also be associated with the stage result and may be shown in visualizations.
Type:String

unstash: Restore files previously stashed


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

name: Name of a previously saved stash.
Type:String

validateDeclarativePipeline: Validate a file containing a Declarative Pipeline




    Checks if the given file (as relative path to current directory) contains a valid Declarative Pipeline.
    Returns true | false.

path: Relative (/-separated) path to file within a workspace to validate as a Declarative Pipeline.
Type:String

waitForBuild: Wait for build to complete


    
        Wait on a build to complete.
    
    
        Use the Pipeline Snippet Generator to generate a sample pipeline script for the waitforBuild step.

runId: The externalizableId of the build to wait on.
Type:String

propagate (optional): If enabled, then the result of this step is that of the downstream build being waited on (e.g., success, unstable, failure, not built, or aborted). If disabled (default state), then this step succeeds even if the downstream build is unstable, failed, etc.; use the result property of the return value as needed.
Type:boolean
propagateAbort (optional): Type:boolean

waitUntil: Wait for condition


    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 up to a maximum of 15 seconds.)
    There is no limit to the number of retries,
    but if the body throws an error that is thrown up immediately.

initialRecurrencePeriod (optional): Sets the initial wait period, in milliseconds, between retries. Defaults to 250ms. Each failure will slow down the delay between attempts up to a maximum of 15 seconds.
Type:long
quiet (optional): If true, the step does not log a message each time the condition is checked. Defaults to false.
Type:boolean

warnError: Catch error and set build and stage result to unstable


    Executes its body, and if an exception is thrown, sets the overall build result
    and the stage result to UNSTABLE, prints a specified message and
    the thrown exception to the build log, and associates the stage result with the
    message so that it can be displayed by visualizations.
    Equivalent to catchError(message: message, buildResult: 'UNSTABLE', stageResult: 'UNSTABLE').

message: A message that will be logged to the console if an error is caught. The message will also be associated with the stage result and may be shown in visualizations.
Type:String

catchInterruptions (optional): If true, certain types of exceptions that are used to interrupt the flow of execution for Pipelines will be caught and handled by the step. If false, those types of exceptions will be caught and immediately rethrown. Examples of these types of exceptions include those thrown when a build is manually aborted through the UI and those thrown by the timeout step. Defaults to true.
Type:boolean

withAnt: With Ant


  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.

installation (optional): Name of an Ant installation to use so that ant will be in the path.
Type:String
jdk (optional): Name of an Java installation to use when running Ant.
Type:String

withChecks: Inject checks properties into its closure

name: Type:String

includeStage (optional): Appends the stage name to the check, this can be useful when you have multiple types of tests in different stages
Type:boolean

withCredentials: Bind credentials to variables

Allows various kinds of credentials (secrets) to be used in idiosyncratic ways. (Some steps explicitly ask for credentials of a particular kind, usually as a credentialsId parameter, in which case this step is unnecessary.) Each binding will define an environment variable active within the scope of the step. You can then use them directly from any other steps that expect environment variables to be set:


node {
  withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {
    sh '''
      set +x
      curl -u "$USERPASS" https://private.server/ > output
    '''
  }
}

    As another example (use Snippet Generator to see all options):

node {
  withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')]) {
    sh '''
      set +x
      curl -H "Token: $TOKEN" https://some.api/
    '''
  }
}

    Note the use of single quotes to define the script
    (implicit parameter to sh) in Groovy above.
    You want the secret to be expanded by the shell as an environment variable.
    The following idiom is potentially less secure, as the secret is interpolated by Groovy
    and so (for example) typical operating system process listings will accidentally disclose it:

node {
  withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')]) {
    sh /* WRONG! */ """
      set +x
      curl -H 'Token: $TOKEN' https://some.api/
    """
  }
}

    At least on Linux, environment variables can be obtained by other processes running in the same account,
    so you should not run a job which uses secrets on the same node as a job controlled by untrusted parties.
    In any event, you should always prefer expansion as environment variables to inclusion in the command,
    since Jenkins visualizations such as Blue Ocean will attempt to detect step parameters containing secrets
    and refuse to display them.


    The secret(s) will be masked (****) in case they are printed to the build log.
    This prevents you from accidentally disclosing passwords and the like via the log.
    (Bourne shell set +x, or Windows batch @echo off,
    blocks secrets from being displayed in echoed commands;
    but build tools in debug mode might dump all environment variables to standard output/error,
    or poorly designed network clients might display authentication, etc.)
    The masking could of course be trivially circumvented;
    anyone permitted to configure a job or define Pipeline steps
    is assumed to be trusted to use any credentials in scope however they like.


    Beware that certain tools mangle secrets when displaying them.
    As one example, Bash (as opposed to Ubuntu’s plainer Dash) does so with text containing ' in echo mode:

$ export PASS=foo"'"bar
$ env|fgrep PASS
PASS=foo'bar
$ sh -xc 'echo $PASS'
+ echo foo'bar
foo'bar
$ bash -xc 'echo $PASS'
+ echo 'foo'\''bar'
foo'bar


    Mangled secrets can only be detected on a best-effort basis. By default, Jenkins will attempt to mask mangled
    secrets as they would appear in output of Bourne shell, Bash, Almquist shell and Windows batch. Without these strategies in place, mangled secrets
    would appear in plain text in log files. In the example above, this would result in:

+ echo 'foo'\''bar'
****

    This particular issue can be more safely prevented by turning off echo with set +x or avoiding the use
    of shell metacharacters in secrets.


    For bindings which store a secret file, beware that

node {
  dir('subdir') {
    withCredentials([file(credentialsId: 'secret', variable: 'FILE')]) {
      sh 'use $FILE'
    }
  }
}

    is not safe, as $FILE might be inside the workspace (in subdir@tmp/secretFiles/),
    and thus visible to anyone able to browse the job’s workspace.
    If you need to run steps in a different directory than the usual workspace, you should instead use

node {
  withCredentials([file(credentialsId: 'secret', variable: 'FILE')]) {
    dir('subdir') {
      sh 'use $FILE'
    }
  }
}

    to ensure that the secrets are outside the workspace; or choose a different workspace entirely:

node {
  ws {
    withCredentials([file(credentialsId: 'secret', variable: 'FILE')]) {
      sh 'use $FILE'
    }
  }
}

    Also see the
    Limitations of Credentials Masking
    blog post for more background.

bindings

Array/List:

Nested choice of objects

certificate


    Sets one variable to the username and one variable to the password given in the credentials.



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the text of the secret, for example on Linux using ps e.

keystoreVariable: Name of an environment variable to be set to the temporary keystore location during the build. The contents of this file are not masked.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

aliasVariable (optional): Name of an environment variable to be set to the keystore alias name of the certificate during the build.
Type:String
passwordVariable (optional): Name of an environment variable to be set to the password during the build.
Type:String

dockerCert

variable: Name of an environment variable to be set during the build. Its value will be the absolute path of the directory where the {ca,cert,key}.pem files will be created. You probably want to call this variable DOCKER_CERT_PATH, which will be understood by the docker client binary.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

file


    Copies the file given in the credentials to a temporary location, then sets the variable to that location.
    (The file is deleted when the build completes.)



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the contents of this file.

variable: Name of an environment variable to be set during the build. The contents of this location are not masked.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

gitUsernamePassword

gitToolName


    
        Specify the Git tool installation name

Type:String

credentialsId


    Set the git username / password credential for HTTP and HTTPS protocols.


Shell example
withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id',
                 gitToolName: 'git-tool')]) {
  sh 'git fetch --all'
}




Batch example
withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id',
                 gitToolName: 'git-tool')]) {
  bat 'git submodule update --init --recursive'
}




Powershell example
withCredentials([gitUsernamePassword(credentialsId: 'my-credentials-id',
                 gitToolName: 'git-tool')]) {
  powershell 'git push'
}

Type:String

sshUserPrivateKey


    Copies the SSH key file given in the credentials to a temporary location, then sets a variable to that location.
    (The file is deleted when the build completes.) Also optionally sets variables for the SSH key's username and passphrase.



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the contents of this file.

keyFileVariable: Name of an environment variable to be set to the temporary path of the SSH key file during the build. The contents of this file are not masked.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

passphraseVariable (optional): Name of an environment variable to be set to the password during the build. (optional)
Type:String
usernameVariable (optional): Name of an environment variable to be set to the username during the build. (optional)
Type:String

string


    Sets a variable to the text given in the credentials.



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the text of the secret, for example on Linux using ps e.

variable: Name of an environment variable to be set during the build. The contents of this location are not masked.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

usernameColonPassword


    Sets a variable to the username and password given in the credentials, separated by a colon (:).



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the text of the secret, for example on Linux using ps e.

variable: Name of an environment variable to be set during the build. The contents of this location are not masked.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

usernamePassword


    Sets one variable to the username and one variable to the password given in the credentials.



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the text of the secret, for example on Linux using ps e.

usernameVariable: Name of an environment variable to be set to the username during the build.
Type:String
passwordVariable: Name of an environment variable to be set to the password during the build.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

zip


    Unpacks the ZIP file given in the credentials to a temporary directory, then sets the variable to that location.
    (The directory is deleted when the build completes.)



    Warning: if the Jenkins controller or agent node has multiple executors,
    any other build running concurrently on the same node will be able to read
    the contents of this directory.

variable: Name of an environment variable to be set during the build. The contents of this location are not masked.
Type:String
credentialsId: Credentials of an appropriate type to be set to the variable.
Type:String

withEnv: Set environment variables


Sets one or more environment variables within a block.
The names of environment variables are case-insensitive but case-preserving, that is, setting `Foo` will change the value of `FOO` if it already exists.
Environment variables 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.

overrides: A list of environment variables to set, each in the form VARIABLE=value or VARIABLE= to unset variables otherwise defined. You may also use the syntax PATH+WHATEVER=/something to prepend /something to $PATH.
Array/List:
Type:String

withGradle: WithGradle

wrap: General Build Wrapper


    
    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.

delegate

Nested choice of objects

withAnt


  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.

installation (optional): Name of an Ant installation to use so that ant will be in the path.
Type:String
jdk (optional): Name of an Java installation to use when running Ant.
Type:String

$class: 'BuildScanBuildWrapper'

$class: 'TimestamperBuildWrapper'

writeFile: Write file to workspace


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

file: Relative path of a file within the workspace.
Type:String
text: The data to write in the file.
Type:String

encoding (optional): The target encoding for the file. If left blank, the platform default encoding will be used. If the text is a Base64-encoded string, the decoded binary data can be written to the file by specifying "Base64" as the encoding.
Type:String

ws: Allocate workspace


    Allocates a workspace.
    Note that a workspace is automatically allocated for you with the node step.

dir: 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 the lock step. If you do not care about locking, just use the dir step to change current directory.
Type:String

`Advanced/Deprecated Steps`

archive: Archive artifacts


Archives build output artifacts for later use.
As of Jenkins 2.x, this step is deprecated in favor of the more configurable archiveArtifacts.

includes: Include artifacts matching this Ant style pattern. Use a comma separated list to add more than one expression.
Type:String

excludes (optional): Exclude artifacts matching this Ant-style pattern. Use a comma-separated list to add more than one expression.
Type:String

dockerFingerprintFrom: Record trace of a Docker image used in FROM


    Records the fact that a Docker image was built from another.

    Deprecated: Fingerprints produced by this step are not used anywhere, and the parsing code has major limitations. 
    See https://github.com/jenkinsci/docker-workflow-plugin/pull/149#issuecomment-451305522 and https://groups.google.com/d/msg/jenkinsci-dev/k13SfZcBWVg/iQghmCQrEAAJ

    If are a user of the Docker Traceability plugin you need to call this Step manually during the build. The mentioned limitations
    will limit the useability of this step for this purpose.

dockerfile: Workspace-relative path of a Dockerfile which will be parsed for its FROM instruction.
Type:String
image: ID or tag of the image which was just built, like --tag of docker build.
Type:String

commandLine (optional): Type:String
toolName (optional): Type:String

dockerFingerprintRun: Record trace of a Docker image run in a container


    Records the fact that a Docker image was used by this build.

    Deprecated: Fingerprints produced by this step are not used anywhere, and the parsing code has major limitations. 
    See https://github.com/jenkinsci/docker-workflow-plugin/pull/149#issuecomment-451305522 and https://groups.google.com/d/msg/jenkinsci-dev/k13SfZcBWVg/iQghmCQrEAAJ

    If are a user of the Docker Traceability plugin you need to call this Step manually during the build. The mentioned limitations
    will limit the useability of this step for this purpose.

containerId: Type:String

toolName (optional): Type:String

envVarsForTool: Fetches the environment variables for a given tool in a list of 'FOO=bar' strings suitable for the withEnv step.

toolId: Type:String
toolVersion: Type:String

getContext: Get contextual object from internal APIs

Obtains a contextual object as in StepContext.get; cf. withContext. Takes a single type argument. Example:


getContext hudson.FilePath

    For use from trusted code, such as global libraries, which can manipulate internal Jenkins APIs.

type

java.lang.UnsupportedOperationException: do not know how to categorize attributes of type java.lang.Class<?>

unarchive: Copy archived artifacts into the workspace

mapping (optional)

java.lang.UnsupportedOperationException: do not know how to categorize attributes of type java.util.Map<java.lang.String, java.lang.String>

withContext: Use contextual object from internal APIs within a block

Wraps a block in a contextual object as in BodyInvoker.withContext; cf. getContext. Takes a single context argument plus a block. Example:


withContext(new MyConsoleLogFilter()) {
    sh 'process'
}

    Automatically merges its argument with contextual objects in the case of ConsoleLogFilter, LauncherDecorator, and EnvironmentExpander.


    For use from trusted code, such as global libraries, which can manipulate internal Jenkins APIs.


    Do not attempt to pass objects defined in Groovy;
    only Java-defined objects are supported.
    Really you should avoid using this and getContext and just define a Step in a plugin instead.

context

Nested choice of objects: (not enumerable)

withDockerContainer: Run build steps inside a Docker container


    Normally used implicitly by method calls on the docker global variable.
    Takes an image ID or symbolic name which must already have been pulled locally
    and starts a container based on that image.
    Runs all nested sh steps inside that container.
    The workspace is mounted read-write into the container.

image: Type:String

args (optional): Any other arguments to pass to docker run.
Type:String
toolName (optional): Type:String

withDockerRegistry: Sets up Docker registry endpoint


    Normally used implicitly by method calls on the docker global variable.
    Sets up connection details for a Docker registry.

registry

Nested object

url: URL to the Docker registry you are using. May be left blank to use the public DockerHub registry (currently https://index.docker.io/v1/).
Type:String
credentialsId: Type:String

toolName (optional): Type:String

withDockerServer: Sets up Docker server endpoint


    Normally used implicitly by method calls on the docker global variable.
    Sets up connection details for a Docker server.

server

Nested object

uri: URI to the Docker Host you are using. May be left blank to use the Docker default (defined by DOCKER_HOST environment variable) (typically unix:///var/run/docker.sock or tcp://127.0.0.1:2376).
Type:String
credentialsId: Type:String