You can use API token for authentication instead by checking "Use API Token for authentication". You can get your API token from your user configuration page.

"Run as Specific User" restricts the job configuration only to the specified user. Other users cannot configure the job even if the Jenkins access control configuration allows it.

This option disabled that feature, and the job configuration is controlled by the Jenkins access control.

Use this feature carefully, for a malicious user can run unintended commands without authentication by changing configuration of the job. Check the access control configuration, and ensure that the CONFIGURE permission for this job is granted only to proper users.

For compatibility, as a fallback when nothing else matches, a simple path like "foo/bar" can also be treated as "/foo/bar".

For compatibility, as a fallback when nothing else matches, a simple path like "foo/bar" can also be treated as "/foo/bar".

Populate as environment variables the shared objects (configured in the 'Manage Section > Shared Objects' section).
With this option, you can dynamically inject environment variables in the build from objects in your environment.

Restrict shared objects propagation to a list of profiles.
Give all the profiles selected.
Each profile will be separated by a semicolon (;).

Populate as environment variables the locations of installed tools (configured in the 'Manage Jenkins > Configure System' section ).
Tool names are exposed as an environment variables. Tool Paths are the environment variable values.
Space ( ), Dash (-) and dot (.) are replaced by an underscore (_) for tool names.

• Sonatype Nexus 3
• JFrog Artifactory 7 / Cloud

Define the URL of the repository instance.

• Artifactory OSS - http://localhost:8082/artifactory/
• Artifactory Cloud - https://tenant.jfrog.io/artifactory/
• Nexus - http://localhost:8081/

Select the credentials to use to connect to the artifact repository instance.

Please be aware that currently only username/password credentials are supported.

When checked the HTTP connection will ignore invalid certificates while trying to connect to the repository instance. This is useful when using an internal service with self-signed certificates.

Use this feature with caution as it can introduce potential security risks.

When checked it allows to define an HTTP proxy to be used for the outgoing connections.

Select the type of information to display as a build parameter.

Unfortunately the REST APIs do not allow for more powerful filter possibilities in regards to the artifact name. If more advanced filter possibilities are required please refer to the Filter Regex option within the Display Options section below.

The REST API of Nexus only allows to define a single repository. To harmonize the UI it was decided to limit the possibility to define repositories for Artifactory to a single entry as well.

This field allows to define a Java capturing groups to extract version information from the full artifact path. In a nutshell define a regex and define a part of a string as a group by surrounding it with ( ) brackets to define a group. The first outer group found is used to extract the version information. Following is an example for a Maven artifact with the regex .+/(\d+\.\d+(\.\d+((-CANDIDATE)?-SNAPSHOT)?)?)/.+.

This allows to filter the results returned from the repository before displaying it to the user for selection. Any entry matching the regular expression will be displayed.
To display all entries either leave the field empty or use the regular expression .+.

A typical regex for Maven-based artifacts would for example look like .+/(\d+\.\d+(\.\d+(-SNAPSHOT)?)?)/.+

Please note that when a regex matches multiple entries but the display style is set to either radio button or dropdown then only the first match wins as those types do not allow for multiple entries to be selected. Furthermore, the regex is always checked against the full path and not just the displayed value.

Example:

Displayed Value: artifact-1.0.0-SNAPSHOT.jar
Full Path: http://localhost:8081/foo/bar/com.example.group/artifact/artifact-1.0.0-SNAPSHOT.jar

By default the plugin will not only submit the label but also some hidden value containing the path of the item represented by the label. Sometimes however one only wants to get the value visible in the label. This option will allow you to choose what information will get passed along to the build script.

• Label + Path (default) - This will send both the label and the hidden path to the build pipeline. Both information are split by a ; (semi-colon).
• Label Only - This will only send the visible label text to the build pipeline.
• Path Only - This will only send a non-visible path of the artifact/repository to the build pipeline.

Example

Label + Path  = commons-lang3-3.12.0.jar;http://localhost:8082/repository/.../commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
Label Only    = commons-lang3-3.12.0.jar
Path Only     = http://localhost:8082/repository/.../commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
        

The name of the parameter.

This value is used for display purposes only - it is not exposed as an environment variable.

Triggering a build from an external source
As the two fields are still presented to Jenkins as a single parameter, a slightly different approach is required to to pass in both the application id and release number from other jobs or via a build api request. This is supported by separating the two values using the pipe character '|'. The applicationId is optional, can contain either an Id or applicaton name, and is only supported if this field is checked.

• ReleaseNumber: 0.0.0
• ApplicationId and ReleaseNumber: 1|0.0.0
• ApplicationName and ReleaseNumber: BuildMaster%20Application|0.0.0

• CLEARCASE_BASELINE, which is replaced with the name of the ClearCase UCM baseline which is selected at build-time;
• JOB_NAME, which is replaced with the name of the job;
• USER_NAME, which is replaced with the name of the user running Hudson.

• The name of the ClearCase UCM view is available as CLEARCASE_VIEWNAME;
• The absolute path to the ClearCase UCM view is available as CLEARCASE_VIEWPATH.

choice1
choice2
choice3

• Tag - list of all commit tags in repository - returns Tag Name
• Branch - list of all branch in repository - returns Branch Name
• Revision - list of all revision sha1 in repository followed by its author and date - returns Tag SHA1

• none
• ascending smart
• descending smart
• ascending
• descending

The mode that you select here will influence the final value of the parameter, when you build the child:

• If you select "Overwritable", the build will just get the value "Bar"
• If you select "Extensible", the build will get the value "FooBar" (or "Foo Bar", depending on the "Whitespace Mode" below)
• If you select "Fixed", then the build will fail, since this project prohibited changing the value.

1. Trim all leading/trailing whitespace from the entered value.
2. Keep the whitespace intact, exactly as the user entered it.
3. Keep the whitespace, but make sure that at least a single space is added to the front of the value, in case it extends a parameter with the same name from a parent.

Do note that, if trimming is selected, this has an effect on both the default value used for automatically started builds, as well as user-initiated builds where the user had a chance to alter the parameter value.

Optionally, specify a comma-delimited list of fields to use instead of the issue summary as the title in the dropdown. Fields will be concatenated with spaces.

Example:

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

(EXAMPLE-100)

Specify a regular expression which release names have to match to be listed. Leave this blank to match all issues.

Example:

• All Nodes - trigger the job on all selected nodes, regardless of their online/offline state
• Ignore Offline Nodes - trigger the job only on nodes being online and having an executor
• Ignore Temp Offline Nodes - trigger the job on all selected nodes except on the ones currently manually marked as offline

• none
• ascending smart
• descending smart
• ascending
• descending

• Tag - list of all commit tags in repository - returns Tag Name
• Branch - list of all branch in repository - returns Branch Name

You can also specify the root of a Subversion repository: If this root contains the trunk, branches and tags folders, then the dropdown will display trunk, all the branches and all the tags. If the root does not contain these three folders, then all its subfolders are listed in the dropdown.

When you enter the URL, Jenkins automatically checks if it can connect to it. If access requires authentication, you'll be prompted for the necessary credential. If you already have a working credential but would like to change it for some other reasons, you can manage credentials and specify a different credential.

If this option is checked, the Sort Z to A one won't be taken into account.

Notice that if Sort newest first is checked, this option won't be taken into account.

A Groovy expression to specify which combinations are checked by default. They are also combinations which is built in a scheduled build. If not specified, the combination filter of this multi-configuration project is used. Also see help of the combination filter.

Note that you cannot enable combinations which disabled by the combination filter of the project.

• FIRST - will evaluate to the first item in the drop-down that would have been presented had the build been executed manually.
• LAST - will evaluate to the last item in the drop-down that would have been presented had the build been executed manually.
• RELEASE - will evaluate to the version marked as RELEASE in the repository metadata for the configured artifact. The versionFilter even if defined is ignored for this default value.
• LATEST - will evaluate to the version marked as LATEST in the repository metadata for the configured artifact. The versionFilter even if defined is ignored for this default value.

When no pattern is specified, the whole content will be displayed.

When a standard pattern is specified, only its first match in the content will be displayed.

When a pattern with a capturing group is specified, only the first group of its first match in the content will be displayed.

• All Nodes - trigger the job on all selected nodes, regardless of their online/offline state
• Ignore Offline Nodes - trigger the job only on nodes being online and having an executor
• Ignore Temp Offline Nodes - trigger the job on all selected nodes except on the ones currently manually marked as offline

• group:name:version
• group:name
• name

If you need to access the repository outside of the repository, you will need grant access to the S3 bucket.

When accessing it from within AWS, it's probable that the server itself provides the necessary access rights.

When accessing it from outside, you need to provide a key pair. These are set up in the AWS admin console. If you don't have access, please ask operations to create a new key pair with access to the specified bucket.

This is the AWS secret key setup in the AWS console. It will resemble the form: ‘AAAAAAAAAA2AAA2AAAAA’

If you don't have access to the AWS console, and you need an access key pair, please contact someone in operations.

This is the AWS secret key setup in the AWS console. It will resemble the form: ‘XxXXXxx/1ZZz1zZZZ11zzZ1zz/YyYyYyyYyyyyYY’

If you don't have access to the AWS console, and you need an access key pair, please contact someone in operations.

This should be set to a valid bucket name that you can access using the key value pair, or if within AWS, that the server has access to.

Ensure that the bucket specified contains the repo. It might sound obvious, but I just wanted to point that out.

This is the path to the actual repo containing the artifacts, relative to the AWS S3 bucket.

For example, given the S3 bucket ‘vhols-common-test-yumrepo’, the path to the locations-public-api repo is repos/locations-public-api

If you need to access the repository outside of the repository, you will need grant access to the S3 bucket.

When accessing it from within AWS, it's probable that the server itself provides the necessary access rights.

When accessing it from outside, you need to provide a key pair. These are set up in the AWS admin console. If you don't have access, please ask operations to create a new key pair with access to the specified bucket.

This is the AWS secret key setup in the AWS console. It will resemble the form: ‘AAAAAAAAAA2AAA2AAAAA’

If you don't have access to the AWS console, and you need an access key pair, please contact someone in operations.

This is the AWS secret key setup in the AWS console. It will resemble the form: ‘XxXXXxx/1ZZz1zZZZ11zzZ1zz/YyYyYyyYyyyyYY’

If you don't have access to the AWS console, and you need an access key pair, please contact someone in operations.

This should be set to a valid bucket name that you can access using the key value pair, or if within AWS, that the server has access to.

Ensure that the bucket specified contains the repo. It might sound obvious, but I just wanted to point that out.

This is the path to the actual repo containing the artifacts, relative to the AWS S3 bucket.

For example, given the S3 bucket ‘vhols-common-test-yumrepo’, the path to the locations-public-api repo is repos/locations-public-api

• `NONE` if there is no authentication requirement simply don't select any _Credential ID_
• `BASIC` if this authentication type is required, then simply select any Username and Password credential in the _Credential ID_ field
• `BEARER` if this authentication type is required, then simply select any Secret Text credential in the _Credential ID_ field

• APPLICATION_JSON - Json-Path syntax is expected in the Value Expression
  
• APPLICATION_XML - xPath syntax is expected in the Value Expression

• Json-Path Syntax Cheatsheet Playground
• xPath Syntax Cheatsheet Playground

• Json-Path Syntax Cheatsheet Playground
• xPath UNSUPPORTED Due to the limitation of the XML parser.

• NONE - Do not apply any post ordering on the received values
• ASC - "Ascending" order gets applied on the received values
• DSC - "Descending" order gets applied on the received values

These parameters are exposed to build as environment variables.

Standard Java regular expression that will be used to validate the entered string parameter value.

This message is displayed to the user if they enter a value that does not match the configured regular expression.

This message is displayed to the user if they enter a value that is not a syntactical correct YAML

• Single Select: user chooses a single selection from a drop down menu, populated by either explicit values (see Value field below) or a property file (see Property File and Property Key fields below)
  
  
• Multi Select: a user can choose multiple selections from a multi-line box, populated by either explicit values (see Value field below) or a property file (see Property File and Property Key fields below)
  
  
• Check Boxes: user can check off zero or more check boxes, labeled by either explicit values (see Value field below) or a property file (see Property File and Property Key fields below)
  
  
• Multi-Level Single Select: user chooses a selection from a drop down, and then a another drop down appears with selections that depend on the first value, and upon second selection a third drop down may appear depending on the first two selections, and so on.
  
  The property file is a tab delimited file, with levels defined in columns and choices defined in rows. For example, to have a 2 level selection where you first select a country and then a city, you could specify a file such as the following:
  
  

  Country	City
  United States	San Francisco
  United States	Chicago
  Mexico	Mexico City
  Mexico	Cancun
              

  This would result in a first drop down with the options "Select a country...", "United States", and "Mexico" (the initial selection is "Select a country...", which serves as a label for the drop down). After the user selects a country, a "City" drop down would appear. If United States was chosen first, then San Francisco and Chicago would be options, but if Mexico was selected then instead Mexico City and Cancun would be options.
  
  The columns that should represent levels must be specified in the value field. For example "Country,City" could be valid values.
  
  Note that default values are not supported for multi-level selects.
  
  
• Multi-Level Multi Select: same as single select, but after all levels are chosen, a button appears to "Select another..." and an additional multi-level selection is presented.

prop1=a,b,c,d,e
prop2=${prop1},f,g,h

prop1=a,b,c,d,e
prop2=1,2,3,4

Inserts this value between selections when the parameter is a multi-select.

The default when empty is ','

• Single Select: user chooses a single selection from a drop down menu, populated by either explicit values (see Value field below) or a property file (see Property File and Property Key fields below)
  
  
• Multi Select: a user can choose multiple selections from a multi-line box, populated by either explicit values (see Value field below) or a property file (see Property File and Property Key fields below)
  
  
• Check Boxes: user can check off zero or more check boxes, labeled by either explicit values (see Value field below) or a property file (see Property File and Property Key fields below)
  
  
• Multi-Level Single Select: user chooses a selection from a drop down, and then a another drop down appears with selections that depend on the first value, and upon second selection a third drop down may appear depending on the first two selections, and so on.
  
  The property file is a tab delimited file, with levels defined in columns and choices defined in rows. For example, to have a 2 level selection where you first select a country and then a city, you could specify a file such as the following:
  
  

  Country	City
  United States	San Francisco
  United States	Chicago
  Mexico	Mexico City
  Mexico	Cancun
              

  This would result in a first drop down with the options "Select a country...", "United States", and "Mexico" (the initial selection is "Select a country...", which serves as a label for the drop down). After the user selects a country, a "City" drop down would appear. If United States was chosen first, then San Francisco and Chicago would be options, but if Mexico was selected then instead Mexico City and Cancun would be options.
  
  The columns that should represent levels must be specified in the value field. For example "Country,City" could be valid values.
  
  Note that default values are not supported for multi-level selects.
  
  
• Multi-Level Multi Select: same as single select, but after all levels are chosen, a button appears to "Select another..." and an additional multi-level selection is presented.

prop1=a,b,c,d,e
prop2=${prop1},f,g,h

prop1=a,b,c,d,e
prop2=1,2,3,4

Inserts this value between selections when the parameter is a multi-select.

The default when empty is ','

If TFS is also used as the repository server, this can usually be left blank.

OPTIONAL: Select the credentials to use.
If not specified, defaults to the DefaultAWSCredentialsProviderChain behaviour - *FROM THE JENKINS INSTANCE*

In the latter case, usage of IAM Role Profiles seems not to work, thus relying on environment variables / system properties or the ~/.aws/credentials file, thus not recommended.

.*\[maven-release-plugin\].*

(?s).*FOO.*

    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  

    myapp/src/main/web/.*\.html
    myapp/src/main/web/.*\.jpeg
    myapp/src/main/web/.*\.gif
  

What to specify

The repository name. In git the repository is always the name of the remote. So if you have specified a repository name in your Git configuration. You need to specify the exact same name here, otherwise no integration will be performed. We do the merge based on this.

No trailing slash on repository name.

Remember to specify this when working with NAMED repositories in Git

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.

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

auto_build_user

If given, "GIT_COMMITTER_NAME=[this]" and "GIT_AUTHOR_NAME=[this]" are set for builds. This overrides whatever is in the global settings.

If given, "GIT_COMMITTER_EMAIL=[this]" and "GIT_AUTHOR_EMAIL=[this]" are set for builds. This overrides whatever is in the global settings.

No approval necessary.

No check of approvals will be performed before building.

Any approval required

Before building the pull request must be approved. This may be performed by the author or someone else.

Non-author approval required

Before building the pull request must be approved and that approval cannot be performed by the author of the pull request.

Author and Non-author approval required

Before building the pull request must be approved by the author and a non-author.

Provide an additional query string to search for open changes. The status:open is implicitly added and does not need to be specified. See Gerrit search operators documentation for a detailed list of the supported search operators.

Examples:

• -is:wip

  does not include work-in-progress changes

• is:private

  includes private changes

Merging the merge request with the current target branch revision

Discover each merge request once with the discovered revision corresponding to the result of merging with the current revision of the target branch

The current merge request revision

Discover each merge request once with the discovered revision corresponding to the merge request head revision without merging

Both the current merge request revision and the merge request merged with the current target branch revision

Discover each merge 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 merge request head revision without merging

One of the great powers of merge requests is that anyone with read access to a project can fork it, commit some changes to their fork and then create a merge request against the original project with their changes. There are some files stored in source control that are important. For example, a Jenkinsfile may contain configuration details to sandbox merge requests in order to mitigate against malicious merge requests. In order to protect against a malicious merge request itself modifying the Jenkinsfile to remove the protections, you can define the trust policy for merge requests from forks.

Other plugins can extend the available trust policies. The default policies are:

Nobody

Merge 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 project and not from the merge request branch on the fork project.

Members

Merge requests from collaborators to the origin project will be treated as trusted, all other merge requests from fork repositories will be treated as untrusted. Note that if credentials used by Jenkins for scanning the project does not have permission to query the list of contributors to the origin project then only the origin account will be treated as trusted - i.e. this will fall back to Nobody.

Trusted Members

Merge requests forks will be treated as trusted if and only if the fork owner has either Developer or Maintainer or Owner Access Level in the origin project. This is the recommended policy.

Everyone

All merge requests from forks will be treated as trusted. NOTE: this option can be dangerous if used on a public project hosted on a GitLab instance.