How to wait for a user to enter a declarative pipeline without blocking a heavyweight performer

Question

I am rebuilding an existing assembly pipeline as a jenkins declarative pipeline (multi-branch pipeline) and have problems processing the assembly.

After packing and storing all the relevant files, the pipeline must wait for user input to start the deployment.

If I just add an input step, the current build-node is blocked. Since this performer is quite heavy, I would like to move this step to a lighter car.

First, I completed the task as a script and only created two different node('label') blocks. is there any way to do something similar with declarative syntax?

 node('spine') { stage('builder') { sh 'mvn clean compile' stash name: 'artifact', includes: 'target/*.war' } } node('lightweight') { stage('wait') { timeout(time:5, unit:'DAYS') { input message:'Approve deployment?' } } // add deployment stages } 

I already tried a couple of things:

setting up the agent at the top level and adding an additional agent configuration to the distribution step, but then I have two executors blocking, since the not installed top-level construction of the node does not stop.

Configure agent none at the top level and configure agents for each step. then the git check is missing on the first node.

EDIT 1

i reconfigured my pipeline after your advice, currently it looks like this:

 pipeline { agent none tools { maven 'M3' } stages { stage('Build') { agent { label 'spine' } steps { checkout scm // needed, otherwise the workspace on the first step is empty sh "mvn clean compile" } } stage('Test') { agent { label 'spine' } steps { sh "mvn verify" // fails because the workspace is empty aggain junit '**/target/surefire-reports/TEST-*.xml' } } } } 

this assembly will fail because the workspace does not migrate between steps because they do not run on the same artist.

EDIT 2

apparently, sometimes the steps are performed on the same artist, and sometimes not. (we create a workstation on our mesos / dcos cluster on demand, so changing the executive mid-build will be a problem)

I expected jenkins to simply start with the current executor until the label in the agent definition changes.

Answer 1

See best practice 7 : Dont: use input in a node block. In the declarative pipeline, node selection is performed using the agent directive.

The documentation here describes how you can define none for the pipeline, and then use the agent level directive to run the steps on the required nodes. I also tried the other way around (we define a global agent on some node, and then we define none at the scene level for input), but this will not work. If the conveyor has assigned a slave, you cannot release the slave for one or more specific steps.

This is the structure of our conveyor :

 pipeline { agent none stages { stage('Build') { agent { label 'yona' } steps { ... } } stage('Decide tag on Docker Hub') { agent none steps { script { env.TAG_ON_DOCKER_HUB = input message: 'User input required', parameters: [choice(name: 'Tag on Docker Hub', choices: 'no\nyes', description: 'Choose "yes" if you want to deploy this build')] } } } stage('Tag on Docker Hub') { agent { label 'yona' } when { environment name: 'TAG_ON_DOCKER_HUB', value: 'yes' } steps { ... } } } } 

Typically, the assembly steps are performed on a slave assembly labeled "yona", but the input stage is performed on the master.

Answer 2

Another way to do this is to use the expression directive and beforeAgent, which skips the "solve" step and avoids confusion with the global "env":

 pipeline { agent none stages { stage('Tag on Docker Hub') { when { expression { input message: 'Tag on Docker Hub?' // if input is Aborted, the whole build will fail, otherwise // we must return true to continue return true } beforeAgent true } agent { label 'yona' } steps { ... } } } } 

Answer 3

use the agent not from above and define an agent for each step, except for the step, including the input step.

source: discussion in Use a lightweight executor for the declarative pipeline stage (agent none)

Updated: what do you mean by "there is no git check on the first node"? show what you still have for the declarative pipeline.

Answer 4

I know that this branch is old, but I believe that the solution to the "Change 2" problem, in addition to saving, is to use nested steps.

https://jenkins.io/blog/2018/07/02/whats-new-declarative-piepline-13x-sequential-stages/#running-multiple-stages-with-the-same-agent-or-environment-or -options

According to this page:

... if you use several agents in your pipeline, but want to be sure that the steps using the same agent use the same workspace, you can use the parent step with the agent directive, and then all the steps inside it The stage directive will be executed for the same artist in the same workspace.

Here is an example:

 pipeline { agent none stages { stage("build and test the project") { agent { docker "our-build-tools-image" } stages { stage("build") { steps { sh "./build.sh" } } stage("test") { steps { sh "./test.sh" } } } post { success { stash name: "artifacts", includes: "artifacts/**/*" } } } stage("deploy the artifacts if a user confirms") { input { message "Should we deploy the project?" } agent { docker "our-deploy-tools-image" } steps { sh "./deploy.sh" } } } }