Jenkins Simple Pipeline Configuration: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(32 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Internal=
=Internal=
* [[Jenkins_Concepts#.28Simple.29_Pipeline|Jenkins Concepts]]
* [[Jenkins_Concepts#.28Simple.29_Pipeline|Jenkins Concepts]]
* [[Jenkins Pipeline Syntax]]
=New Item=
==Enter an item name==
<font color=darkgray>No spaces?</font>


=General=
=General=


====Description====
====Description====
"Artifact pipeline that runs tests, packages and publishes ..."
====Jira site====
====Discard old builds====
====Discard old builds====
Yes
Yes
Line 11: Line 22:
Keeping fewer builds means less disk space will be used in the Build Record Root Directory, which is specified on the Configure System screen.
Keeping fewer builds means less disk space will be used in the Build Record Root Directory, which is specified on the Configure System screen.


Strategy: Log Rotation
Max # of builds to keep: 10
Advanced:
====Do not allow concurrent builds====
Leave unchecked.
====Do not allow the pipeline to resume if the master restarts====
Leave unchecked.
====GitHub project====
Leave unchecked.
====Delivery Pipeline configuration====
Leave unchecked.
====Pipeline speed/durability override====
Leave unchecked.
====Preserve stashes from completed builds====
Leave unchecked.
====Rebuild options====
Leave unchecked.
====This project is parameterized====
For more details about parameterized builds and parameter declaration, see: {{Internal|Jenkins_Pipeline_Parameters#UI_Parameters|Jenkins Pipeline Parameters &#124; UI Parameters}}
String Parameter
Name: branch
Default Value: develop
Description: The branch to build on
Trim te string: check
====Throttle Concurrent Builds====
Check
====Throttle this project alone/Throttle this project as part of one or more categories====
Select "Throttle this project alone"
====Maximum Total Concurrent Builds====
5
The maximum number of concurrent builds of this project (or category) to be allowed to run at any one time, across all nodes.
====Maximum Concurrent Builds Per Node====
====Prevent multiple jobs with identical parameters from running concurrently====
Leave unchecked.
====Throttle builds====
Leave unchecked.
====Prepare an environment for the run====
Leave unchecked.


=Build Triggers=
=Build Triggers=
====Build after other projects are built====
Leave unchecked.
====Build periodically====
Leave unchecked.
====Build when another project is promoted====
Leave unchecked.
====GitHub Pull Request Builder====
Leave unchecked.
====GitHub hook trigger for GITScm polling====
Leave unchecked.
====Poll SCM====
Leave unchecked.
====Disable this project====
Leave unchecked.
====Quiet period====
Leave unchecked.
====Trigger builds remotely (e.g., from scripts)====
Leave unchecked.
=Advanced Project Options=


=Advanced Pipeline Options=
Display Name


=Pipeline=
=Pipeline=
====Definition====
<span id='Pipeline_Script_from_SCM'></span>Pipeline script from SCM
====SCM====
Git
====Repositories====
Repository URL:
https://github.com/novaordis/test.git
Credentials:
====Branches to build====
Used to specify the branches to pull the pipeline definition, as Jenkinsfile from. If left blank, all branches will be examined for changes and built. <font color=darkgray>How?</font>.
The recommended way to specify a branch is to use the refs/heads/<branchName> syntax. This way the expected branch is unambiguous. For more details see [[#refs.2Fheads.2F.3CbranchName.3E|refs/heads/<branchName>]] below. 
If the branch name contains a "/" separator, 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, so "foo/bar" will actually match bar. Wildcards can be used. If a wildcard  with a slash is used as branch specifier (e.g. release/), you'll need to specify the origin repository in the branch names to make sure changes are picked up: "origin/release/". For more details see [[#.3CWildcards.3E|<Wildcards>]] below.
<span id='Checkout_Sequence'></span>The typical checkout sequence after specifying "Pipeline script from SCM"/Git is:
<syntaxhighlight lang='text'>
Started by user someuser@somedomain.com
Checking out git https://github.com/ovidiuf/playground.git into /var/lib/jenkins/workspace/test-1@script to read jenkins/pipelines/simple-pipeline/Jenkinsfile
The recommended git tool is: NONE
No credentials specified
Cloning the remote Git repository
Cloning repository https://github.com/ovidiuf/playground.git
> git init /var/lib/jenkins/workspace/test-1@script # timeout=10
Fetching upstream changes from https://github.com/ovidiuf/playground.git
> git --version # timeout=10
> git --version # 'git version 2.18.4'
> git fetch --tags --progress -- https://github.com/ovidiuf/playground.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url https://github.com/ovidiuf/playground.git # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
Avoid second fetch
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision f945af0013d77729f46b979b974075a633e7b800 (refs/remotes/origin/master)
Enabling Git LFS pull
> git config core.sparsecheckout # timeout=10
> git checkout -f f945af0013d77729f46b979b974075a633e7b800 # timeout=10
> git config --get remote.origin.url # timeout=10
> git lfs pull origin # timeout=10
Commit message: "some relevant commit message"
First time build. Skipping changelog.
Running in Durability level: MAX_SURVIVABILITY
</syntaxhighlight>
'''Options:'''
=====<tt><branchName></tt>=====
Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one. To avoid ambiguity, use a fully qualified branch name: refs/heads/<branchName>.
=====<tt>refs/heads/<branchName></tt>=====
Tracks/checks out the specified branch.
=====<tt><remoteRepoName>/<branchName></tt>=====
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>.
=====<tt>remotes/<remoteRepoName>/<branchName></tt>=====
Tracks/checks out the specified branch: "remotes/origin/master"
=====<tt>refs/remotes/<remoteRepoName>/<branchName></tt>=====
Tracks/checks out the specified branch: "refs/remotes/origin/master"
=====<tt><tagName></tt>=====
This does not work since the tag will not be recognized as tag. Use refs/tags/<tagName> instead.
=====<tt>refs/tags/<tagName></tt>=====
Tracks/checks out the specified tag: "refs/tags/git-2.3.0"
=====<tt><commitId></tt>=====
Checks out the specified commit: 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
=====<tt>${ENV_VARIABLE}</tt>=====
The environment variable is evaluated and the result is used as described above: ${TREEISH}, refs/tags/${TAGNAME}, ...
=====<tt><Wildcards></tt>=====
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.
=====<tt>:<regular expression></tt>=====
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
====Repository browser====
(Auto)
====Additional Behaviors====
Prune stale remote-tracking branches
Advanced clone behaviors
Fetch tags: Disabled
Honor refspec on initial clone: Enabled
Shallow clone: Enabled
Shallow clone depth: 20
Path of the reference repo to use during clone:
Timeout (in minutes) for clone and fetch operations: 20
====Script Path====
infra/something.Jenkinsfile
====Lightweight checkout====
If selected, try to obtain the Pipeline script contents directly from the SCM without performing a full checkout. The advantage of this mode is its efficiency; however, you will not get any changelogs or polling based on the SCM. If you use "checkout scm" during the build, this will populate the changelog and initialize polling. Also build parameters will not be substituted into SCM configuration in this mode. Only selected SCM plugins support this mode.
Disabled.

Latest revision as of 19:17, 25 March 2021

Internal

New Item

Enter an item name

No spaces?

General

Description

"Artifact pipeline that runs tests, packages and publishes ..."

Jira site

Discard old builds

Yes

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.

Strategy: Log Rotation

Max # of builds to keep: 10

Advanced:

Do not allow concurrent builds

Leave unchecked.

Do not allow the pipeline to resume if the master restarts

Leave unchecked.

GitHub project

Leave unchecked.

Delivery Pipeline configuration

Leave unchecked.

Pipeline speed/durability override

Leave unchecked.

Preserve stashes from completed builds

Leave unchecked.

Rebuild options

Leave unchecked.

This project is parameterized

For more details about parameterized builds and parameter declaration, see:

Jenkins Pipeline Parameters | UI Parameters

String Parameter

Name: branch

Default Value: develop

Description: The branch to build on

Trim te string: check

Throttle Concurrent Builds

Check

Throttle this project alone/Throttle this project as part of one or more categories

Select "Throttle this project alone"

Maximum Total Concurrent Builds

5

The maximum number of concurrent builds of this project (or category) to be allowed to run at any one time, across all nodes.

Maximum Concurrent Builds Per Node

Prevent multiple jobs with identical parameters from running concurrently

Leave unchecked.

Throttle builds

Leave unchecked.

Prepare an environment for the run

Leave unchecked.

Build Triggers

Build after other projects are built

Leave unchecked.

Build periodically

Leave unchecked.

Build when another project is promoted

Leave unchecked.

GitHub Pull Request Builder

Leave unchecked.

GitHub hook trigger for GITScm polling

Leave unchecked.

Poll SCM

Leave unchecked.

Disable this project

Leave unchecked.

Quiet period

Leave unchecked.

Trigger builds remotely (e.g., from scripts)

Leave unchecked.

Advanced Project Options

Display Name

Pipeline

Definition

Pipeline script from SCM

SCM

Git

Repositories

Repository URL:

https://github.com/novaordis/test.git

Credentials:

Branches to build

Used to specify the branches to pull the pipeline definition, as Jenkinsfile from. If left blank, all branches will be examined for changes and built. How?.

The recommended way to specify a branch is to use the refs/heads/<branchName> syntax. This way the expected branch is unambiguous. For more details see refs/heads/<branchName> below.

If the branch name contains a "/" separator, 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, so "foo/bar" will actually match bar. Wildcards can be used. If a wildcard with a slash is used as branch specifier (e.g. release/), you'll need to specify the origin repository in the branch names to make sure changes are picked up: "origin/release/". For more details see <Wildcards> below.

The typical checkout sequence after specifying "Pipeline script from SCM"/Git is:

Started by user someuser@somedomain.com
Checking out git https://github.com/ovidiuf/playground.git into /var/lib/jenkins/workspace/test-1@script to read jenkins/pipelines/simple-pipeline/Jenkinsfile
The recommended git tool is: NONE
No credentials specified
Cloning the remote Git repository
Cloning repository https://github.com/ovidiuf/playground.git
 > git init /var/lib/jenkins/workspace/test-1@script # timeout=10
Fetching upstream changes from https://github.com/ovidiuf/playground.git
 > git --version # timeout=10
 > git --version # 'git version 2.18.4'
 > git fetch --tags --progress -- https://github.com/ovidiuf/playground.git +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url https://github.com/ovidiuf/playground.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
Avoid second fetch
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision f945af0013d77729f46b979b974075a633e7b800 (refs/remotes/origin/master)
Enabling Git LFS pull
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f945af0013d77729f46b979b974075a633e7b800 # timeout=10
 > git config --get remote.origin.url # timeout=10
 > git lfs pull origin # timeout=10
Commit message: "some relevant commit message"
First time build. Skipping changelog.
Running in Durability level: MAX_SURVIVABILITY

Options:

<branchName>

Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one. To avoid ambiguity, use a fully qualified branch name: refs/heads/<branchName>.

refs/heads/<branchName>

Tracks/checks out the specified branch.

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

remotes/<remoteRepoName>/<branchName>

Tracks/checks out the specified branch: "remotes/origin/master"

refs/remotes/<remoteRepoName>/<branchName>

Tracks/checks out the specified branch: "refs/remotes/origin/master"

<tagName>

This does not work since the tag will not be recognized as tag. Use refs/tags/<tagName> instead.

refs/tags/<tagName>

Tracks/checks out the specified tag: "refs/tags/git-2.3.0"

<commitId>

Checks out the specified commit: 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...

${ENV_VARIABLE}

The environment variable is evaluated and the result is used as described above: ${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>

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

Repository browser

(Auto)

Additional Behaviors

Prune stale remote-tracking branches

Advanced clone behaviors

Fetch tags: Disabled

Honor refspec on initial clone: Enabled

Shallow clone: Enabled

Shallow clone depth: 20

Path of the reference repo to use during clone:

Timeout (in minutes) for clone and fetch operations: 20

Script Path

infra/something.Jenkinsfile

Lightweight checkout

If selected, try to obtain the Pipeline script contents directly from the SCM without performing a full checkout. The advantage of this mode is its efficiency; however, you will not get any changelogs or polling based on the SCM. If you use "checkout scm" during the build, this will populate the changelog and initialize polling. Also build parameters will not be substituted into SCM configuration in this mode. Only selected SCM plugins support this mode.

Disabled.