Jenkins Simple Pipeline Configuration: Difference between revisions
(16 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= | ||
Line 36: | Line 43: | ||
Leave unchecked. | Leave unchecked. | ||
====This project is parameterized==== | ====This project is parameterized==== | ||
For more details about parameterized builds and parameter declaration, see: {{Internal|Jenkins_Pipeline_Parameters#UI_Parameters|Jenkins Pipeline Parameters | UI Parameters}} | |||
String Parameter | String Parameter | ||
Name: branch | Name: branch | ||
Line 42: | Line 51: | ||
Description: The branch to build on | Description: The branch to build on | ||
Trim te string: check | |||
====Throttle Concurrent Builds==== | ====Throttle Concurrent Builds==== | ||
Line 88: | Line 99: | ||
====Definition==== | ====Definition==== | ||
Pipeline script from SCM | <span id='Pipeline_Script_from_SCM'></span>Pipeline script from SCM | ||
====SCM==== | ====SCM==== | ||
Line 103: | Line 114: | ||
====Branches to build==== | ====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>. | |||
$branch | |||
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==== | ====Repository browser==== | ||
Line 133: | Line 209: | ||
====Lightweight checkout==== | ====Lightweight checkout==== | ||
Disabled | 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:
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.