Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

"Jenkins 2.x practice Guide" Reading Notes-Jenkins 2.x pipeline Grammar

2025-01-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/02 Report--

[TOC]

1. Have a general understanding of Groovy

You can learn about it through the Groovy tutorial.

2. Pipeline introduction

Jenkins pipeline is actually a DSL (domain specific language) based on the Groovy language to describe how the entire pipeline works. The content of the pipeline includes the steps of compiling, packaging, testing, outputting test reports and so on.

2.1 pipeline Minimalist structure pipeline {agent any stages {stage ('Stage 1') {steps {echo' Hello worldview'} pipeline: represents the entire pipeline, including the logic of the entire pipeline. Stage section: phase, which represents the stage of the pipeline. Each stage must have a name. In this case, build is the name of this phase. Stages section: containers for multiple stage in the pipeline. The stages section contains at least one stage. Steps section: a container that represents one or more concrete steps (step) in a phase. The steps section contains at least one step, which in this case is echo. There is one and only one steps in a stage. Agent section: specify the execution location (Jenkins agent) of the pipeline. Each phase in the pipeline must be performed somewhere (physical machine, virtual machine, or Docker container), and the agent part specifies exactly where.

Refer to the documentation for more detailed pipeline steps:

Https://jenkins.io/zh/doc/pipeline/steps/

Each of the above parts (section) is required, one less, Jenkins will report an error.

As we all know, jenkins is easy to use and the many plug-ins that best reflect it meet a variety of needs. Not all plug-ins support pipeline.

Jenkins plug-in compatible pipeline list:

Https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md

2.2 post

The post section contains additional steps after the entire pipeline or phase is completed. The post section is optional, so it is not included in the minimalist structure of pipeline. But that doesn't mean it doesn't work.

Depending on the completion status of the pipeline or phase, the post part is divided into a variety of conditional blocks, including:

Always: executes regardless of the current completion status. Changed: executes as long as the current completion status is different from the previous completion status. Fixed: the last completion status was failed or unstable (unstable), and the current completion status is executed when it is successful. Regression: executes when the last completion status is successful and the current completion status is failed, unstable, or aborted (aborted). Aborted: when the current execution result is aborted (usually artificially aborted). Failure: executes when the current completion status is failed. Success: executes when the current completion status is successful. Unstable: executes when the current completion status is unstable. Cleanup: clean up the condition block. Regardless of the current completion status, it is executed after all other conditional block execution is completed. The post section can contain multiple conditional blocks at the same time. The following is a complete example of the post section. Pipeline {agent any stages {stage ('Build') {steps {sh' echo Build stage...'} post {always {echo "post condition executed: always..."} changed { Echo "post condition executed: changed..."} aborted {echo "post condition executed: aborted..."} regression {echo "post condition executed: regression..."} stage (' Test') {steps {sh 'echo Test stage...'} post {aborted {echo "post condition executed: aborted..."} failure {echo "post condition executed: failure..." } success {echo "post condition executed: success..."} stage ('Deploy') {steps {sh' echo Deploy stage...'}} post {unstable { Echo "post condition executed: unstable..."} unsuccessful {echo "post condition executed: unsuccessful..."} cleanup {echo "post condition executed: cleanup..."}} 2.3 pipeline supported directives

Obviously, the basic structure can not meet the changing needs of reality. Therefore, Jenkins pipeline enriches itself with various instructions (directive). Instructions can be understood as a supplement to the basic structure of Jenkins pipeline.

The directives supported by Jenkins pipeline are:

Environment: used to set environment variables, which can be defined in the stage or pipeline section. Tools: can be defined in the pipeline or stage section. It automatically downloads and installs the tool we specified and adds it to the PATH variable. Input: defined in the stage section, pipeline will be paused and you will be prompted for input. Options: an option to configure Jenkins pipeline itself, such as options {retry (3)}, which means to retry twice when pipeline fails. The options instruction can be defined in the stage or pipeline section. Parallel: execute multiple step in parallel. After the pipeline plug-in version 1.2, parallel began to support parallel execution of multiple phases. Parameters: unlike input, parameters is some of the parameters passed in before pipeline is executed. Triggers: used to define the trigger that executes pipeline. When: the phase is executed when the conditions defined by when are met.

When using instructions, it is important to note that each instruction has its own "scope". If the instruction is not in the correct location, Jenkins will report an error.

2.4Configuring pipeline itself 2.4.1 Global options

The options directive allows pipelining-specific options to be configured from within the pipeline. Pipelining provides many of these options, such as buildDiscarder, but can also be provided by plug-ins, such as timestamps.

RequiredNoParametersNoneAllowedOnly once, inside the pipeline block. Available option

BuildDiscarder

Saves the component and console output for a specific number of recent pipelined runs. For example: options {buildDiscarder (logRotator (numToKeepStr:'1'))}

DisableConcurrentBuilds

Pipelining is not allowed to execute at the same time. Can be used to prevent simultaneous access to shared resources, etc. For example: options {disableConcurrentBuilds ()}

OverrideIndexTriggers

Allows default processing of branch index triggers to be overridden. If branch index triggers are disabled in multiple branches or organization tags, options {overrideIndexTriggers (true)} will only allow them to facilitate work. Otherwise, options {overrideIndexTriggers (false)} will only disable branch index triggers that change jobs.

SkipDefaultCheckout

In the agent directive, skip the default of checking out code from source control. For example: options {skipDefaultCheckout ()}

SkipStagesAfterUnstable

Once the build state becomes UNSTABLE, skip this phase. For example: options {skipStagesAfterUnstable ()}

CheckoutToSubdirectory

Source control checkout is performed automatically in a subdirectory of the workspace. For example: options {checkoutToSubdirectory ('foo')}

Timeout

Sets the timeout for the pipeline to run, after which Jenkins will abort the pipeline. For example: options {timeout (time: 1, unit: 'HOURS')}

Retry

On failure, the specified number of times to retry the entire pipeline. For example: options {retry (3)}

Timestamps

Premeditate all console output generated by the pipeline at the same time as the pipeline. For example: options {timestamps ()}

NewContainerPerStage

When agent is docker or dockerfile, you specify that each stage runs in a new container on the same Jenkins node, instead of all stage running in the same container. For example: options {newContainerPerStage ()}

Examplepipeline {agent any options {timeout (time: 1, unit: 'HOURS')} stages {stage (' Example') {steps {echo 'Hello World'}

Specify a global execution timeout of one hour, after which Jenkins will abort the pipeline.

2.4.2 Phase option

The options instruction of stage is similar to the options instruction on the pipeline root. However, the stage-level options can only include steps such as retry, timeout, or timestamps, or declarative options related to stage, such as skipDefaultCheckout.

In stage, the steps in the options instruction are called before entering the agent or checked when the when condition occurs.

Optional phase option

SkipDefaultCheckout

Skip the default check-out code from source control in the agent directive. For example: options {skipDefaultCheckout ()}

Timeout

Sets the timeout for this phase, after which Jenkins terminates the phase. For example: options {timeout (time: 1, unit: 'HOURS')}

Retry

On failure, retry this phase a specified number of times. For example: options {retry (3)}

Timestamps

It is premeditated that all console output generated at this stage and the time at which the line is emitted are consistent. For example: options {timestamps ()}

Examplepipeline {agent any stages {stage ('Example') {options {timeout (time: 1, unit:' HOURS')} steps {echo 'Hello World'}

Specify the execution timeout for the Example phase, after which Jenkins will abort the pipeline.

2.4.3 using scripts in declarative pipeline

Declarative pipeline does not allow you to write Groovy code directly in steps blocks.

Jenkins pipeline specifically provides a script step in which you can write pipeline logic as if you were writing code in the script step.

Pipeline {agent any stages {stage ('Build') {steps {script {result = sh (script: "git log-1 | grep' Release'", returnStatus: true) echo "result: ${result}"}

What is in the script block is actually the Groovy code. Most of the time, we don't need to use the script step. If you write a lot of logic in the script step, you should split the logic into different stages or put it in a shared library. Shared library is a technology that extends Jenkins pipeline.

2.5 pipeline built-in basic steps

Here are some of the steps built into pipeline.

2.5.1 steps related to file directory

DeleteDir

Delete the current directory, which is a no-parameter step, and delete the current working directory. It is usually used with the dir step to delete the contents of the specified directory.

Dir

Change to the directory. The default pipeline works in the workspace directory, and the dir step allows us to switch to another directory. For example: dir ("/ var/logs") {deleteDir ()}

FileExists

Determine whether the file exists. FileExists ('/ tmp/a.jar') determines whether the / tmp/a.jar file exists. If the parameter is a relative path, it is determined whether the file exists relative to the current working directory. The result returns a Boolean type.

IsUnix

Determine whether it is a Unix-like system. Returns true if the current pipeline is running on a Unix-like system.

Pwd

Confirm the current directory. Pwd, like Linux's pwd command, returns the current directory. It has an optional parameter of Boolean type: tmp, which returns the temporary directory associated with the current workspace if the parameter value is true.

WriteFile

Writes the contents to the specified file.

The parameters supported by writeFile are:

File: file path, either absolute or relative. Text: the contents of the file to be written. Encoding (optional): the encoding of the target file. If left blank, the default encoding of the operating system is used. If you are writing Base64 data, you can use Base64 encoding.

ReadFile

Reads the contents of the specified file and returns it as text.

The parameters supported by readFile are:

File: path, which can be either absolute or relative. Encoding (optional): the encoding used when reading the file. Script {/ / "amVua2lucyBib29r" is the Base64-encoded value of "jenkins book" writeFile (file: "base64File", text: "amVua2lucyBib29r", encoding: "Base64") def content = readFile (file: "base64File", encoding: "UTF-8") echo "${content}" / / print result: jenkins book} 2.5.2 Product related steps

Stash

Save the temporary file.

The stash step can save some files for use by other steps or phases of the same build. If all phases of the entire pipeline are performed on the same machine, the stash steps are redundant. Therefore, files that usually require stash are used across Jenkins node.

The stash step stores files in tar files, and stash operations for large files consume Jenkins master's computing resources. The Jenkins official documentation recommends that when the file size is 5 ∼ 100MB, other alternatives should be considered.

The list of parameters for the stash step is as follows:

Name: string type, unique identification of the collection where the file is saved. AllowEmpty: Boolean type that allows stash content to be empty. Excludes: string type, which files are excluded. If multiple files are excluded, they are separated by commas. Leaving blank means that no documents are excluded. Includes: string type, which files to stash, leave blank to represent all files under the current folder. UseDefaultExcludes: Boolean type. If true, it means that the file list is excluded by default using the Ant style path.

Except for the name parameter, all parameters are optional. Excludes and includes use Ant-style path expressions.

Unstash

Take out the previous stash file.

The unstash step has only one name parameter, which is the unique identity of the stash. Stash is usually used in conjunction with the unstash step. The following is a complete example.

Pipeline {agent none stages {stage ('stash') {agent {label "master"} steps {script {writeFile file: "a.txt", text: "$BUILD_NUMBER" stash (name: "abc") Include: "a.txt")} stage ("unstash") {agent {label "node2"} steps {script {unstash ("abc") def content = readFile ("a.txt") Echo "${content}"}

The stash step is performed on the master node, while the unstash step is performed on the node2 node.

2.5.3 Command related steps

The steps related to the command are actually provided by the Pipeline:Nodes and Processes plug-in. Because it is a component of the Pipeline plug-in, there is little need to install it separately.

Sh

Execute the shell command.

The parameters supported by the sh step are:

Script: the shell script to be executed, which can usually be a multiline script on a UNIX-like system. Encoding: outputs the encoding of the log after the script is executed. The default value is the encoding of the system on which the script runs. ReturnStatus: Boolean type. The default script returns a status code. If it is a nonzero status code, it will cause pipeline execution to fail. If the returnStatus parameter is true, the execution of pipeline will not be affected regardless of the status code. ReturnStdout: Boolean type, if true, the standard output of the task will be printed as the return value of the step, rather than printed to the build log (if there are errors, it will still be printed to the log). Except for the script parameter, all parameters are optional.

The returnStatus and returnStdout parameters are generally not used at the same time, because there can only be one return value. If used at the same time, only the returnStatus parameter takes effect.

Bat 、 powershell

The bat step executes the batch command of Windows. The powershell step executes a PowerShell script that supports the 3 + version. These two steps support the same parameters as the sh step.

2.5.4 other steps

Error

Actively report an error and abort the current pipeline.

The execution of the error step is similar to throwing an exception. It has only one required parameter: message. The parameter: error ("there's an error") is usually omitted.

Tool

Use predefined tools.

If the tool is configured in Global Tool Configuration (Global tool configuration), the tool path can be obtained through the tool step.

The parameters supported by the tool step are:

Name: tool name. Type (optional): tool type, which refers to the full path class name of the tool installation class.

The type value for each plug-in is different, and most plug-in documentation does not write type values at all. In addition to looking in the plug-in's source code, another way to quickly find the type value is to go to the Jenkins pipeline snippet generator to generate the code for the tool step.

Timeout

Code block timeout.

Sets the timeout limit for code running within the timeout step closure. If it times out, an org.jenkinsci.plugins.workflow.steps.FlowInterruptedException exception will be thrown. The timeout step supports the following parameters:

Time: integer, timeout. Unit (optional): unit of time. Supported values are NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS, MINUTES (default), HOURS, DAYS. Activity (optional): Boolean type, if the value is true, it is only when the log has no activity that it really counts as a timeout.

WaitUntil

Wait for the conditions to be met.

Repeat the code within the waitUntil block until the condition is true. WaitUntil is not responsible for handling exceptions in block code and throws them directly when an exception is encountered. The waitUntil step is best used in conjunction with the timeout step to avoid an endless loop. Examples are as follows:

Timeout (50) {waitUntil {script {def r = sh script: 'curl http://example', returnStatus: true retturn (r = = 0)}

Retry

Repeat execution block

Execute the scripts in the N closures. If one of the execution throws an exception, only this execution is aborted, not the entire retry execution. At the same time, the user cannot abort the retry during the execution of the pipeline.

Steps {retry (20) {script {sh script: 'curl http://example', returnStatus: true}

Sleep

Let pipeline sleep for a while.

The sleep step can be used to simply pause pipeline, which supports the following parameters:

Time: integer, dormancy time. Unit (optional): unit of time. Supported values are NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS (default), MINUTES, HOURS, DAYS. 2.5.5 Tips Jenkins provides a pipeline snippet generator that can generate code through interface operations. (only pipeline projects have "Pipeline Syntax menu") VS Code extension: Jenkins Pipeline Linter Connector, which supports syntax checking of Jenkinsfile. Clean up the space using the Workspace Cleanup plug-in. Ant style path expression.

There are three wildcard matching methods for Apache Ant-style paths, which can be used to combine multiple path patterns:

WildcardDescription? Match any single character * matches 0 or any number of characters, does not include / * * matches 0 or more directories, does not include /

Example of Ant style path matching:

PathDescription/app/*.x match (Matches) all .x files / app/p?ttern matches (Matches) / app/pattern and / app/pXttern under the app path, but does not include / project/example, / project/foow/example, and / example/app/**/dir/file under the root path of the / app/pttern/**/example match project. Match (Matches) / app/dir/file.jsp, / app/foo/dir/file.html,/app/foo/bar/dir/file.pdf, and / app/dir/file.java/**/*.jsp match any .jsp file under the project root path

It is important to note that path matching follows the longest matching principle (has more characters). For example, / app/dir/file.jsp matches the path patterns of / * * / * .jsp and / app/dir/*.jsp, so it is ultimately based on the latter.

Reference:

[1] "Jenkins 2.x practical Guide"

[2] https://jenkins.io/zh/doc/book/pipeline/syntax/

[3] https://jenkins.io/zh/doc/pipeline/steps/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report