The syntax of the use of Jenkins pipeline:pipeline

First, Introduction

With the advent of Jenkins 2.0, Pipline entered the field of vision, Jenkins2.0 's core character. It is also the most suitable feature for continuous delivery.

Simply put, the Jenkins1.0 version, project configuration information, such as the configuration of svn/git, parameter configuration, etc. all become code, that is, pipeline as code.

With the pipeline delivery pipeline being promoted in the team, the job using the pipeline script also increased rapidly.

Advantage: Configure project in the form of writing code, and Jenkins has built-in common steps. The construction step code is realized and the building process is viewed. Ii. Introduction to Grammar

The most basic part of pipeline is "step". Basically, step tells Jenkins what to do and serves as a basic building block for declarative pipeline and scripted pipeline syntax.
Pipeline supports two syntaxes: declarative Pipeline (introduced in Pipeline 2.5, structured mode) and scripted Pipeline, both supporting the creation of Pipeline for continuous transport. Choose declarative Pipeline or scripted Pipeline

The first Pipeline plugin, supported by only one type of script, is scripted Pipeline;
Declarative pipeline is a new type of script that pipeline plugin after the 2.5 release and can be used to write scripts like the previous scripted pipeline.

Related information:

Https://stackoverflow.com/questions/43484979/jenkins-scripted-pipeline-or-declarative-pipeline
Http://jenkins-ci.361315.n4.nabble.com/Declarative-pipelines-vs-scripted-td4891792.html

Judging from the data retrieved, declarative Pipeline is the type supported by the subsequent open Blue ocean. Comparatively speaking, declarative pipeline is relatively simple, declarative pipeline, also can embed scripted pipeline code.

For compatibility with the Blueocean Script Editor, it is generally recommended to write using declarative pipeline, which is clearly a future trend from the Jenkins Community's perspective. third, declarative Pipeline

Declarative Pipeline is a relatively new addition to the Jenkins Pipeline, which proposes a more simplified and meaningful syntax on the Pipeline subsystem.
All valid declarative pipeline must be contained within a pipeline block, for example:
Pipeline {/* Insert declarative pipeline here */}
The basic statements and expressions in declarative pipeline follow the same rules as groovy syntax, with the following exceptions: The top level of the a.pipeline must be a block, specifically: pipeline {} b. There is no semicolon as the statement delimiter. 　　Each declaration must be on its own line C. Blocks can only contain sections, directives, steps, or assignment statements. D. The attribute reference statement is treated as a non-argument method call. So for example, input is treated as input () 1.Sections (chapter)

The sections in declarative pipeline usually contains one or more directives or Steps agents

The agent section specifies where the entire pipeline or specific stage will be executed in the Jenkins environment, depending on where the agent portion is placed. 　　 　　This section must be defined at the top level within the pipeline block, but the stage use is optional. To support the various use cases that pipeline may have, the agent section supports several different types of parameters. These parameters can be applied to the top level of the pipeline block, or they can be applied within each stage directive. Parameters 　　 any

Executes the pipeline or stage on any available agent. Example: Agent any
None
When none is used at the top of the pipeline block, the global agent will not be assigned to the entire pipeline run, and each stage section will need to contain its own agent section.
Label
Executes the pipeline or stage on an agent that is available in the Jenkins environment using the provided label label. For example: Agent {label ' My-defined-label '}
Node
Agent {node {label ' LabelName '} is equivalent to Agent {label ' LabelName '}, but node allows other options (such as Customworkspace).
Docker
When this parameter is defined, a docker node is dynamically supplied to accept Docker-based's pipelines when executing pipeline or stage. Docker can also accept a args, which is passed directly to the Docker run call. For example: Agent {docker ' maven:3-alpine '} or

1 2 3 4 5 6 7 8

Docker Agent {docker {image ' maven:3-alpine ' label ' My-defined-label ' args '-v/tmp: /tmp '}}

Dockerfile

Use the containers contained in the Dockerfile source repository to build the execution pipeline or stage. In order to use this option, Jenkinsfile must be loaded from Multibranch Pipeline or "Pipeline from SCM".
The default is the root directory of the Dockerfile Source Library: Agent {dockerfile true}. If the dockerfile needs to be established in another directory, use the following dir option: Agent {dockerfile {dir ' Somesubdir '}}. You can use the Docker build ... Use the Additionalbuildargs option, such as Agent {dockerfile {additionalbuildargs '--build-arg Foo=bar '}}.

Parameters
Any
Executes the pipeline or stage on any available agent. Example: Agent any
None
When none is used at the top of the pipeline block, the global agent will not be assigned to the entire pipeline run, and each stage section will need to contain its own agent section.
Label
Executes the pipeline or stage on an agent that is available in the Jenkins environment using the provided label label. For example: Agent {label ' My-defined-label '}
Node
Agent {node {label ' LabelName '} is equivalent to Agent {label ' LabelName '}, but node allows other options (such as Customworkspace).
Docker
When this parameter is defined, a docker node is dynamically supplied to accept Docker-based's pipelines when executing pipeline or stage. Docker can also accept a args, which is passed directly to the Docker run call. For example: Agent {docker ' maven:3-alpine '} or

Docker
Agent {
    Docker {
        image ' maven:3-alpine '
        label ' My-defined-label '
        args  '-v/tmp:/tmp '
    }
}

Dockerfile
Use the containers contained in the Dockerfile source repository to build the execution pipeline or stage. In order to use this option, Jenkinsfile must be loaded from Multibranch Pipeline or "Pipeline from SCM".
The default is the root directory of the Dockerfile Source Library: Agent {dockerfile true}. If the dockerfile needs to be established in another directory, use the following dir option: Agent {dockerfile {dir ' Somesubdir '}}. You can use the Docker build ... Use the Additionalbuildargs option, such as Agent {dockerfile {additionalbuildargs '--build-arg Foo=bar '}}. Common Options

These are options that can be applied to two or more agents. Unless explicitly defined, it is not required.
Label
A string. Mark where to run pipeline or stage
This option is available for Node,docker and Dockerfile, and node is required.
Customworkspace
A string. Customize the running workspace. It can be a relative path, in which case the custom workspace will be located under the workspace root on the node, or it can be an absolute path. For example:

1 2 3