After more thought Daniel,
Really what I’d like to have, is the ability to apply powerhell code (before and) after a manual intervention step, much like how the Deploy NuGet Package steps optionally work. Ideally this would allow for some sort of mechanism that could execute code conditionally based on the final outcome or result of the manual intervention prompt (ie Proceed vs Abort being clicked).
I would feel that this is a pretty common use-case, as many organizations/teams will have multiple code signoffs before being production worthy. It feels kludgy that we have to wait for the results of all manual interventions to come in, when it should only take ONE abort to fail a deployment!
From: Long, Bradley (Brad)
Sent: Monday, May 23, 2016 9:29 AM
To: ‘Daniel Fischer’ firstname.lastname@example.org
Subject: RE: Parallel Manual Intervention Steps should fail when one fails [Problems #45991]
Thanks for the response Daniel,
I am trying to run manual intervention steps in parallel. we need QA and the Product Owner to sign off on a release before it moves to production; but don’t care in what order they sign off. I have also created a FlowDock integration (via PowerShell script steps) that updates an Inbox Thread with the status/state of these approvals.
The problems arise when either one fails (manual intervention step gets aborted), I don’t want to have to wait for the approval/denial of the other step before fully failing the deployment; and for that matter, wait to update FlowDock.
Bottom-line, I think the FlowDock integration issue goes away if we could just get parallel steps to abort once one of their brother parallel steps have failed. Specifically, when these steps are Manual Intervention ones!
· As you can see the workflow is simply Parallel Steps (two of which are manual intervention steps)
· When the workflow is executed, as expected I see two notifications that the deployment has been paused for the approvals
· Here QA has aborted their approval, and yet the deployment is still stuck waiting for PO to approve/deny as well (it should take only one to deny a deployment!)
· Notice it’s weird that manual interventions flag as completed successfully, however their actual Octopus.Step[name of step].Status.Codes will still be set to “Running”!