>In order to integrate with AWS CodePipeline, you must authorize access to the pipeline and its related artifacts. If you installed Jenkins on a supported Amazon EC2 instance type, such as Amazon Linux, you can install the AWS CLI and configure a profile with the required credentials. This is the preferred method. In all other cases, you can store AWS credentials in these fields. You should securely configure your Jenkins instance to use HTTPS so that these credentials are not sent unencrypted. For more information, see AWS CodePipeline Integration for Other Products and Services.

You might need a proxy host address if you are hosting Jenkins on a private network. The proxy name can be an IP address or DNS address. The AWS CodePipeline Plugin for Jenkins requires internet access. If access is not configured, you might see errors in the AWS CodePipeline Polling Log.

You might need a proxy port for your proxy host address if you are hosting Jenkins on a private network. The proxy port is a number, might be on port 8080, 3128, or 8443, depending on your network protocols and security settings. If access is not configured, you might see errors in the AWS CodePipeline Polling Log.

This is the category of the action type in AWS CodePipeline, and is usually either Build or Test. To see an example usage, see Install and Configure the AWS CodePipeline Plugin for Jenkins.

This is the provider name of the action type in AWS CodePipeline. You must provide this exact string when adding an action for Jenkins in AWS CodePipeline. To see an example usage, see Install and Configure the AWS CodePipeline Plugin for Jenkins.

Leave the default as 1.

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

If you have multiple modules to check out, this option is forced (otherwise they'll overlap.)

This affects other path specifiers, such as artifact archivers --- you now specify "build/foo.jar" instead of "foo/build/foo.jar".

The build quiet period is designed to assist with CVS checkouts by waiting for a specific period of time without commits. Normally you want the checkout to reflect the time when the quiet period was exited successfully. Select this option if you need to re-enable the legacy behaviour of Jenkins, i.e. using the time that the build started checking out as the timestamp for the checkout operation. Note: enabling this option can result in the quiet period being defeated especially in those cases where the build is not able to start immediately after exiting the quiet period.

Contribute data to a global database. Defined in the Compatibility Action Storage Plugin.

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

You normally want to specify this when you have multiple remote repositories.

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.

Mulitple 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 term definition in Git user manual for more details.

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

• https://demo.backlog.jp/projects/DORA

When no value is set, project of "Backlog URL" set above is used.

    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
  

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

If given, "git config user.email [this]" is called before builds. This overrides whatever is in the global settings.

>In order to integrate with AWS CodePipeline, you must authorize access to the pipeline and its related artifacts. If you installed Jenkins on a supported Amazon EC2 instance type, such as Amazon Linux, you can install the AWS CLI and configure a profile with the required credentials. This is the preferred method. In all other cases, you can store AWS credentials in these fields. You should securely configure your Jenkins instance to use HTTPS so that these credentials are not sent unencrypted. For more information, see AWS CodePipeline Integration for Other Products and Services.

You might need a proxy host address if you are hosting Jenkins on a private network. The proxy name can be an IP address or DNS address. The AWS CodePipeline Plugin for Jenkins requires internet access. If access is not configured, you might see errors in the AWS CodePipeline Polling Log.

You might need a proxy port for your proxy host address if you are hosting Jenkins on a private network. The proxy port is a number, might be on port 8080, 3128, or 8443, depending on your network protocols and security settings. If access is not configured, you might see errors in the AWS CodePipeline Polling Log.

This is the category of the action type in AWS CodePipeline, and is usually either Build or Test. To see an example usage, see Install and Configure the AWS CodePipeline Plugin for Jenkins.

This is the provider name of the action type in AWS CodePipeline. You must provide this exact string when adding an action for Jenkins in AWS CodePipeline. To see an example usage, see Install and Configure the AWS CodePipeline Plugin for Jenkins.

Leave the default as 1.

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

If you have multiple modules to check out, this option is forced (otherwise they'll overlap.)

This affects other path specifiers, such as artifact archivers --- you now specify "build/foo.jar" instead of "foo/build/foo.jar".

The build quiet period is designed to assist with CVS checkouts by waiting for a specific period of time without commits. Normally you want the checkout to reflect the time when the quiet period was exited successfully. Select this option if you need to re-enable the legacy behaviour of Jenkins, i.e. using the time that the build started checking out as the timestamp for the checkout operation. Note: enabling this option can result in the quiet period being defeated especially in those cases where the build is not able to start immediately after exiting the quiet period.

Contribute data to a global database. Defined in the Compatibility Action Storage Plugin.

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

You normally want to specify this when you have multiple remote repositories.

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.

Mulitple 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 term definition in Git user manual for more details.

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

• https://demo.backlog.jp/projects/DORA

When no value is set, project of "Backlog URL" set above is used.

    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
  

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

If given, "git config user.email [this]" is called before builds. This overrides whatever is in the global settings.

Select the appropriate Perforce workspace behaviour from the list. Not all modes will suit all Jenkins Job build types.

There are five types:

Manual
Manually define the Workspace view and sync options. Existing workspace will by updated or a new workspace created.
Spec File
Use a pre-defined Workspace Spec file versioned in Perforce.
Static
Use a pre-defined Workspace; must already exist and have a valid view.
Streams
Auto create/update a Streams workspace with a view determined by the chosen stream.
Template
Auto create/update a normal workspace with a view determined by the template workspace.

Lines to map depot files into the client workspace.

Maps files in the depot to files in your client workspace. Defines the files that you want in your client workspace and specifies where you want them to reside. The default view maps all depot files onto the client. See 'p4 help views' for view syntax. A new view takes effect on the next 'p4 sync'.