SCM/JIRA link daemon added a comment - 2015-05-28 18:48 Code changed in jenkins User: Jesse Glick Path: COMPATIBILITY.md http://jenkins-ci.org/commit/workflow-plugin/502baeecf856ec112a265663ff75d4cb4e82affe Log: JENKINS-28632 Noting.

Jesse Glick added a comment - 2015-06-11 21:41 Triggering a downstream Workflow job would be useful, but then you are back to job chaining, so you do not get the benefit of having all the logic in one script. What is crucially missing is a way for a Workflow step to pause until it gets a deployment event. You could perhaps cobble this together in a prototype using the generic waitUntil step and calling a couple of Jenkins APIs to inspect current fingerprints looking for DeploymentFacet , though I do not see a way to find these facets efficiently if you do not already have the MD5 checksum of the event, and anyway this would be polling rather than responding immediately. The proper solution is to have a dedicated Workflow step which registers a DeploymentFacetListener that listens for the equivalent of ThresholdCondition but matching the current build. (There is no “upstream” vs. “downstream” here, and no UpstreamDeploymentCause —you are listening for deployment of artifacts published earlier in the same build. So the design of the Condition extension point is probably not suitable, unless the range is computed and then tested to see if it is a singleton range consisting of the current build.) Thus you might write something like: stage 'Build' node { sh 'make stuff' archive 'bin/stuff' } stage name: 'Stage' , concurrency: 1 input 'Ready to stage?' node { unarchive 'bin/stuff' sh 'scp bin/stuff root@puppethost:/staging' // whatever } def records = awaitDeployment( 'staging' ) // HostRecord[]? node { sh "run-selenium-tests ${records[0].host}" } stage name: 'Production' , concurrency: 1 input 'Ready to promote?' node { unarchive 'bin/stuff' sh 'scp bin/stuff root@puppethost:/production' // whatever } awaitDeployment( 'production' ) mail to: 'ops@mycorp.com' , subject: 'We are live!' where the input and awaitDeployment steps may pause for long periods.

Antonio Muñiz added a comment - 2015-11-20 09:49 node { unarchive 'bin/stuff' sh 'scp bin/stuff root@puppethost:/production' // whatever } awaitDeployment( 'production' ) This proposal splits deployment and wait steps in two separate consecutive instructions, what would happen if the deployment send the finish event notification * before * awaitDeployment started to listen for it? Perhaps something like this would be safer: awaitDeployment( 'production' ) { node { unarchive 'bin/stuff' sh 'scp bin/stuff root@puppethost:/production' // whatever } }