I have a project A with a Deploy a Release step which deploys a release from project B. I start a deployment in A and cancel it. The end result is that the Deploy a Release step is marked as cancelled, but actually project B is deployed.
Problems I can see with this:
1. The cancellation request doesn’t cause child deployment to be cancelled.
Log fragment from project A:
Task ID: ServerTasks-50293 Related IDs: Deployments-25245, Channels-117, Releases-21482, Projects-84, Spaces-1, Environments-1 Task status: Canceled Task queued: Wednesday, 25 September 2019 7:00:16 AM +00:00 Task started: Wednesday, 25 September 2019 7:00:19 AM +00:00 Task completed: Wednesday, 25 September 2019 7:33:32 AM +00:00 Task duration: 33 minutes Server version: 2019.8.3+Branch.tags-2019.8.3.Sha.8a69207dba03d0d0032ece992e1a60a07157ba5b Server node: EC2AMAZ-V9BN36K | == Failed: Deploy AAAAAAAAAAAAAA release 2019.09.25-07.00 to UAT == 07:00:21 Verbose | Guided failure is not enabled for this task 07:24:13 Info | Requesting cancellation... | == Failed: Step 17: BBBBBBBBBBBBBBBBBBBBB == 07:32:52 Fatal | The step failed: This task has been canceled. 07:32:52 Info | The operation was canceled. | | Success: Worker 07:01:19 Verbose | Octopus Server version: 2019.8.3+Branch.tags-2019.8.3.Sha.8a69207dba03d0d0032ece992e1a60a07157ba5b 07:01:19 Verbose | Environment Information: | OperatingSystem: Microsoft Windows 10.0.14393 | OsBitVersion: x64 | Is64BitProcess: True | CurrentUser: EC2AMAZ-V9BN36K\svcOctopusServer | MachineName: EC2AMAZ-V9BN36K | ProcessorCount: 2 | CurrentDirectory: C:\Windows\system32 | TempDirectory: C:\Users\svcOctopusServer\AppData\Local\Temp\ | HostProcessName: Octopus.Server | PID: 2332 07:01:19 Verbose | Creating deployment for release 188.8.131.5224+master of project 'BBBBBBBBBBBBBBBBBBBBB' 07:01:23 Info | Deploying release 184.108.40.20624+master of project 'BBBBBBBBBBBBBBBBBBBBB'. [View deployment](~/app#/Spaces-1/deployments/Deployments-25254) 07:32:52 Info | Deployment of release 220.127.116.1124+master of project 'BBBBBBBBBBBBBBBBBBBBB' completed successfully 07:32:52 Verbose | Updating manifest with output variables 07:32:52 Verbose | Updating manifest with action evaluated variables 07:32:52 Verbose | Successfully finished BBBBBBBBBBBBBBBBBBBBB on a Worker
Log fragment from project B:
Task ID: ServerTasks-50301 Related IDs: Deployments-25254, Channels-246, Releases-21295, Projects-165, Spaces-1, Environments-1 Task status: Success Task queued: Wednesday, 25 September 2019 7:01:19 AM +00:00 Task started: Wednesday, 25 September 2019 7:31:25 AM +00:00 Task completed: Wednesday, 25 September 2019 7:32:51 AM +00:00 Task duration: 1 minute Server version: 2019.8.3+Branch.tags-2019.8.3.Sha.8a69207dba03d0d0032ece992e1a60a07157ba5b Server node: EC2AMAZ-V9BN36K | == Warning: Deploy BBBBBBBBBBBBBBBBBBBBB release 18.104.22.16824+master to UAT == 07:31:26 Verbose | Guided failure is not enabled for this task 07:32:51 Info | The deployment completed successfully. | | == Success: Acquire packages == 07:31:26 Info | Acquiring packages 07:31:26 Info | Making a list of packages to acquire 07:31:26 Verbose | No packages are required on the Octopus Server 07:31:26 Verbose | Delta compression is enabled for package transfers from the Octopus Server to deployment targets 07:32:32 Info | All packages have been acquired 07:32:32 Verbose | Acquire Packages completed |
At the time when cancellation was requested (07:24:13), the child deployment was still not started, so it should have got cancelled.
Event if it was started, but still in package acquisition phase, the cancellation should be propagated from parent to child and the child deployment should be cancelled.
2. The status in parent project is incorrect
Task summary shows:
This clearly suggests that this step was cancelled. But Task Log shows:
Either the child task should really be cancelled (preferred), or at least the status in parent project should correctly show what really happened (that the child project was deployed).