Deploy a Release skips step which is awaiting manual intervention

[jakub.januszkiewicz]

Consider:

• Project A:
  • has a process with some steps
  • there exists a release 1.1.1
• Project B:
  • has a process with a “Deploy a Release from Project A” step
  • the step has Deployment Condition == IfNewer
  • there exists a release 2.2.2 referencing Project A release 1.1.1

Scenario:

1. Developer X deploys Project A release 1.1.1, but it fails and requires manual intervention (it is left as such for now for investigation).
2. Developer Y deploys Project B release 2.2.2. It completes successfully (all steps are green), but it has the following message in the Deploy a Release step: “The project A will not be deployed because the requested release version (1.1.1) is not higher than the currently deployed or queued version (1.1.1).”. Developer doesn’t notice this, as he only inspects logs on failures.
3. Developer X concludes the investigation and chooses Fail as a resolution.

Result: project A is not deployed, but looking at project B suggests that it was deployed. One has to dig into deployment logs to discover that.

It is crucial for a tool like Octopus Deploy to make it 100% clear what the deployment status is, and the scenario above is very misleading and easily leads to incomplete deployments.

Maybe in this scenario the Deploy a Release step should pause until the investigation is finished (so that it can correctly decide if there is still anything to deploy or not)? Or taking this even further, why are queued deployments considered at all at this stage? A queued deployment can be cancelled manually, can fail, can be failed during manual intervention… Shouldn’t Deploy a Release steps be always queued, leaving the decision related to the Deployment Condition to the very last moment, as it is the only time when it can be correctly resolved?

[Kenneth_Bates]

Hi Jakub,

Thanks for getting in touch! You’re absolutely correct that this is currently a limitation with the Deploy a Release steps, and seems to be kind of in the same vein as the issue you pointed out previously with the parent project’s deployment being cancelled but not cancelling the separate child deployment.

Other than adding a new manual intervention step in your parent project (to give you time to double check the deployment of the child), I think it might be possible (though I haven’t had a chance to give this a test) to leverage the system variables to track a deployment’s status, with the available variables listed in the following doc section.

System Variables - Octopus Deploy

Then grab these variables created by the child project’s steps from the parent project. Syntax to do this is found in the following doc section.

Deploy Release Step - Octopus Deploy

I do think you make some great points in regards to this step, and we are currently discussing this in addition to your initial report for the future of this step. I’m sorry it’s not better news for the time being though! We certainly appreciate your input and detailed use case.

Don’t hesitate to reach out if you have any questions or concerns moving forward.

Best regards,

Kenny