Jenkins Pipeline: "input" step blocks executor
You have to use the input step outside any node block, so it does not hold any executor:
stage 'Build'
node('build-node') {
sh 'call you build tool'
stash includes: 'target/my-output-artifact.whatever', name: 'built'
}
input 'Continue to deploy stage?'
stage 'Deploy'
node('deploy-node') {
unstash 'built'
sh 'scp target/my-output-artifact.whatever user@deploy-server:/deploy'
}
And you can lock the deploy stage if you want only one deploy at time:
lock ('deploy-server') {
stage 'Deploy'
node('deploy-node') {
unstash 'built'
sh 'scp target/my-output-artifact.whatever user@deploy-server:/deploy'
}
}
Note that the key part here is the stash
step as you can move artifacts from one node to another (you could share the same node for both actions but the workspace is not granted to be untouched between the two node calls, specially if some time passes waiting on input
).
Given the recent advances of Jenkins pipelines, the probably best way would be the following (source: jenkins.io/blog):
Use milestone
and lock
- The
lock
step (from the lockable-resources plugin) allows to lock some specified resource so that only a single pipeline execution can enter this stage simultaneously (you don't want to run two deployments simultaneously, do you?) - The
milestone
step (from the pipeline-milestone-step plugin) will abort any older pipeline executions, if a more recent build already reached the milestone (you don't want to let an older build that hangs longer in CI overwrite the deployment of a newer build, do you?).
stage('Deploy') {
input "Deploy?"
milestone()
lock('Deployment') {
node {
echo "Deploying"
}
}
}
The Deploy stage does not limit concurrency but requires manual input from a user. Several builds might reach this step waiting for input. When a user promotes a specific build all preceding builds are aborted, ensuring that the latest code is always deployed.
I recommend to read the whole story, which includes further helpful information.
Credits go to @amuniz, who is maintaining these plugins.
EDIT (Oct 2016): Please see my other answer "Use milestone and lock" below, which includes recently introduced features.
Use timeout
Step
As first option, you can wrap your sh
step into a timeout
step.
node() {
stage 'Build to Stage' {
sh '# ...'
}
stage 'Promotion' {
timeout(time: 1, unit: 'HOURS') {
input 'Deploy to Production?'
}
}
stage 'Deploy to Production' {
sh '# ...'
}
}
This stops the build after the timeout.
Move input
Step to Flyweight Executor
Another option is to not allocate a heavyweight executor for the input
step. You can do this by using the input
step outside of the node
block, like this:
stage 'Build to Stage' {
node {
sh "echo building"
stash 'complete-workspace'
}
}
stage 'Promotion' {
input 'Deploy to Production?'
}
stage 'Deploy to Production' {
node {
unstash 'complete-workspace'
sh "echo deploying"
}
}
This is was probably the more elegant way, but can still be combined with the timeout
step.
EDIT: As pointed out by @amuniz, you have to stash/unstash the contents of the workspace, as different nodes respectively workspace directories might be allocated for the two node
steps.