This blog post will be a continuation of
The next feature within Workflow is Gates and Approvals, which allows for human intervention before promotion of code or continuing the workflow. Say we want to alert someone (via email) to validate that our deploy was successful and we should run our test suite. You could add the following to the deploy block:
stage 'Deploy', concurrency: 1 node('deploy-node'){ //deploy your app input 'Run automated test suite?' mail body:'Can you validate this deploy?' + env.BUILD_URL + 'console' , from: '[email protected]', subject: 'Validate Deploy', to: '[email protected]' }
As you can see, I have included a couple things to make the reader’s life a bit easier. The variable env.BUILD_URL is one of the Jenkins set environment variables. This will prompt the user to Proceed or Abort.
Another feature of the Workflow plugin is the ability to deploy a specific artifact to an environment as a groovy function. This feature allows for you to deploy the artifacts that were just built, easily and without the use of an artifact repository. This allows for immature CI pipelines that don’t have an artifact repository (e.g. Sonatype Nexus, Artifactory, etc.), to deploy versioned artifacts.
The final aspect of note involving the Workflow plugin is the allowance for version control of the actual scripts that drive the job. This might not seem very relevant with the use of the Configuration History plugin, but think of developing an enhancement to a pre-existing job. In this case I would have to clone the job, remove all external ramifications (say promoting code at the end of a passed test suite), develop the script and then copy and paste it into the new job. I would also like to point out that you could not see my iterations, and the Configuration History plugin does not allow for comments (commit messages). Hence, in a world where you used version controlled scripts, you could set up your Workflow scripts to work as code, and proceed through a CI pipeline that allows promotion of code.
