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

This article mainly explains "what are the differences between Pipeline script and declarative grammar". The explanation in the article is simple and clear and easy to learn and understand. please follow the editor's train of thought to study and learn "what are the differences between Pipeline script and declarative grammar"?

Why are there two types of pipes?

Scripted pipelines are the first implementation of pipelines as code in Jenkins. Even though it uses the underlying plumbing subsystem, it is more or less designed to be a generic DSL built using Groovy. This means that it does not have a fixed structure, and it is up to you to decide how to define the pipeline logic.

The declarative pipeline is more self-righteous and its structure is clearly defined. It may seem a little limited.

But in practice, you can use scripted or declarative pipes to achieve the same goal. So which one do you choose? If you ask me this question, I would say use declarative channels. The following is why.

1. Code verification at pipeline startup

Pipeline {agent any stages {stage ("Build") {steps {echo "Some code compilation here..."}} stage ("Test") {steps {echo "Some tests execution here..." Echo 1}

If we try to run the following pipeline, validation will quickly cause the build to fail. The log shows only with the trigger String parameter, so we get such an error.

Note that the pipeline does not perform any phase, it just fails. This may save us a lot of time-imagine executing the Build phase for a few minutes and just getting the information you want from the echo step-java.lang.String instead of java.lang.Integer.

Now, let's take a look at the script pipeline equivalent to this example.

Node {stage ("Build") {echo "Some code compilation here..."} stage ("Test") {echo "Some tests execution here..." Echo 1}}

The pipe performs the same phase and the same steps. However, there is one obvious difference. Let's execute it and see what results it produces.

It failed as expected. But this is the first step in the implementation of the Build phase and the Test phase. As you can see, the pipeline code is not validated. In this case, declarative pipelines can better handle such use cases.

two。 Restart from the specified steps

Another cool feature of declarative pipes is to "restart from phase". Let's fix the pipes in the previous example to see if we can only restart the Test phase.

Pipeline {agent any stages {stage ("Build") {steps {echo "Some code compilation here..."}} stage ("Test") {steps {echo "Some tests execution here..."}

Let's execute it.

Here you can see that the test phase has been selected. Above the list of steps on the right, there is an option called restart Test. Let's click it and see the results.

As you can see, Jenkins skips the Build phase (it uses the workspace from the previous build) and starts the next pipeline execution from the Test phase. This can be useful when you perform some external tests and fail due to some problems in the remote environment. You can use the test environment to solve the problem and then rerun the phase without having to rebuild all the artifacts. (in this case, the code of the application has not changed.)

Now, let's take a look at the scripted pipeline example.

Node {stage ("Build") {echo "Some code compilation here..."} stage ("Test") {echo "Some tests execution here..."}}

As you can see, there is no restart option. Declarative and scripted piping-2:0.

3. Declarative pipe options block

Both pipe types support the third feature, but I think declarative pipes handle it better. Suppose we add the following features to the previous pipeline.

The timestamp in the console log.

ANSI color output.

In the 1-minute timeout build phase, the 2-minute timeout test phase.

The declarative pipeline is shown below.

Pipeline {agent any options {timestamps () ansiColor ("xterm")} stages {stage ("Build") {options {timeout (time: 1) Unit: "MINUTES")} steps {sh 'printf "\\ e [31mSome code compilation here...\\ e [0m\\ n"'}} stage ("Test") {options {timeout (time: 2) Unit: "MINUTES")} steps {sh 'printf "\\ e [31mSome tests execution here...\\ e [0m\\ n"'}

Let's run it.

This is the console log.

Started by user Szymon Stepniak Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in / home/wololock/.jenkins/workspace/pipeline-sandbox [Pipeline] {[Pipeline] timestamps [Pipeline] {[Pipeline] ansiColor [Pipeline] {[Pipeline] stage [Pipeline] {(Build) [Pipeline] timeout 15:10:04 Timeout set to expire in 1 min 0 sec [Pipeline] {[Pipeline] sh 15:10:04 + printf'\ e [31mSome Code compilation here...\ e [0m\ n '15:10:04 Some code compilation here... [Pipeline]} [Pipeline] / / timeout [Pipeline]} [Pipeline] / / stage [Pipeline] stage [Pipeline] {(Test) [Pipeline] timeout 15:10:04 Timeout set to expire in 2 min 0 sec [Pipeline] {[Pipeline] sh 15:10:05 + printf'\ e [31mSome tests execution here...\ e [0m\ n '15:10:05 Some tests execution here... [Pipeline]} [Pipeline] / / timeout [Pipeline]} [Pipeline] / / stage [Pipeline]} [Pipeline] / / ansiColor [Pipeline]} [Pipeline] / / timestamps [Pipeline]} [Pipeline] / / node [Pipeline] End of Pipeline Finished: SUCCESS

In declarative pipes, options are separated from pipe script logic. The script pipeline also supports the timestamps,ansiColor and timeout options, but it requires a different code. This is the same pipe expressed using scripted pipes.

Node {timestamps {ansiColor ("xterm") {stage ("Build") {timeout (time: 1) Unit: "MINUTES") {sh 'printf "\\ e [31mSome code compilation here...\\ e [0m\\ n"'}} stage ("Test") {timeout (time: 2) Unit: "MINUTES") {sh 'printf "\\ e [31mSome tests execution here...\\ e [0m\\ n"'}

I think you see the problem. Here, we only use the timestamps and ansiColorJenkins plug-ins. Imagine adding one or two more plug-ins. Declarative and scripted, 3:0.

4. Skip the phase with the when block.

The last thing I want to mention in this blog post is the blocks supported by the when declarative pipeline. Let's improve on the previous example and add the following conditions:

The test phase is executed only when it is equal. Env.FOO`bar

This is the appearance of the declarative pipeline code.

Pipeline {agent any options {timestamps () ansiColor ("xterm")} stages {stage ("Build") {options {timeout (time: 1) Unit: "MINUTES")} steps {sh 'printf "\\ e [31mSome code compilation here...\\ e [0m\\ n"'}} stage ("Test") {when {environment name: "FOO" Value: "bar"} options {timeout (time: 2, unit: "MINUTES")} steps {sh 'printf "\\ e [31mSome tests execution here...\\ e [0m\\ n"'}

And then execute it.

The test phase was skipped as expected. Now, let's try to do the same in the scripted pipeline example.

Node {timestamps {ansiColor ("xterm") {stage ("Build") {timeout (time: 1) Unit: "MINUTES") {sh 'printf "\\ e [31mSome code compilation here...\\ e [0m\\ n"'}} if (env.FOO = = "bar") {stage ("Test") {timeout (time: 2) Unit: "MINUTES") {sh 'printf "\\ e [31mSome tests execution here...\\ e [0m\\ n"'}}

As you can see, we must use if-condition to check whether env.FOO equals bar before adding the Test phase. (unfortunately, this is not really skipping.) Let's run it and see how it turns out.

This is a different result. In scripted pipeline use cases, the "test" phase is not even present. In my opinion, this may lead to some unnecessary confusion, and the declarative pipeline will deal with it better. Declarative and scripted, 4:0.

Thank you for your reading, the above is the content of "what are the differences between Pipeline scripting and declarative grammar". After the study of this article, I believe you have a deeper understanding of what the differences between Pipeline scripting and declarative grammar are, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.