Hello, we are using octopus cli/Jenkins plugin in our pipelines and one of our deployments requires a manual intervention to validate a terraform plan. We usually wrap octopus requests in a retry block in case of random failures/octopus server updates/redeployment.
Is there a way to distinguish an aborted manual step from any other reasons for a failed deployment? We would like to cancel the retry for an aborted manual intervention and from what I tested octopus cli returns code 255 in both this case and deployment failing due to a server error.
Thanks for reaching out and welcome to the Octopus Forums!
I think the best path forward here to distinguish between a failure and an aborted deployment would be to use the API to look at the server task for the deployment and wait for it to finish. Once it is finished, if it failed, check the interruptions and see if it was aborted.
Here is an example:
ServerTask JSON ( /api/tasks/ServerTasks-#######)
deploy the release
$tasksuccess = false
API call to get servertask
while ($completed -eq false){
wait x seconds
API call to servertask to see if it's completed (if it is, set $completed to true, set $tasksuccess to reflect what's in the JSON)
}
if $tasksuccess -eq true, do your actions you want if it's successful
else, go to the interruptions for that task and find out if it was an Abort or a general deployment failure. (You will want to iterate every Item in the interruptions JSON and get Form.Values.Result to see if any of them were Abort)
Then at this point you would have your differing logic based on if it was aborted or failed.
Please let me know if that helps or if you have any questions.
This seems to work, thanks. Too bad we have to do it in such a roundabout way, would be nice if octopus cli just returned a different code for manually aborted deployments.
