Jenkins Pipeline "node inside stage versus" inside node "

Since both the node step and the stage step provide extended {} syntax, what is the best practice for determining their topology inside the groovy code?

Illustration A

 node ("NodeName") { stage ("a stage inside node"){ // do stuff here } } 

Illustration B

 stage ("a stage holding a node") { node ("NodeName"){ // do stuff here } } 
+13
source share
2 answers

It depends on your real needs.

As long as you can run the full pipeline on one node, I would wrap the stage in node so that the pipeline is not blocked by busy statements.

Once you use the parallel step, you really have no choice but to stage around the node .

There are (at least for me) no problems around mixing, i.e. the first 2-3 stages are performed on the same node, and then one stage, which is performed on several nodes within parallel .

+14
source

With node { stage { ... } } each stage will use the same working folder, and all the files in the previous stage will be there for the next stage.

On stage { node { ... } } you have to stash / unstash files between each stage. If you have a large repository, and especially if you have a large dependency folder, such as node_modules , repeated stash / unstash can eventually become significant, or even large, or your build time.

IMO I would usually start with the first syntax, node { stage { ... } } , as preferred. If you have separate build steps that take time and can benefit from concurrency, then switching to stage { node { ... } } might be better if the time obtained from parallelization is not lost during the collection.

Update:

I checked the exact effect of the exchange of attachments on one of our assemblies. with a bunch of steps inside the node, the total build time is just over one minute. With the assembly inside each stage, the total assembly time is almost five minutes. Big difference.

Build stage timing example

0
source

Source: https://habr.com/ru/post/1262833/


All Articles