Release keeps unused Account reference

Octopus Server
, , ,
1

Steps:

  1. Create an Account (ex. Token Account)
  2. Create a Target that authenticates with that Account (ex. Kubernetes Target)
  3. Deploy a Release that goes to the Target
  4. Delete Target (this works)
  5. Delete Account (this is blocked since the Release references the Account)

This is preventing me from cleaning up from delete clusters. The Release doesn’t look like it should be referencing the Account (it’s transitively referenced through the Target that I’m able to delete). There is no way that the Account can be used by Re-Deploying the release since the only Target that used it has been deleted.

3

Hi @rwkarg,

Thanks for getting in touch! I appreciate the clear repro steps and for your input here. I’ve been able to reproduce this exact behavior locally, and I think the difference in behavior around deletion of these two different things is certainly worth consideration. I’ve brought this up internally to decide if/how we should modify how this currently works.

One thing I’ve found is to be able to delete the account, you’d have to at minimum delete the deployments of these releases (as this account usage is stored against the deployment and not the release), but you don’t have to delete the releases themselves.

Thanks again for your report and input here. Please let us know if you have any questions or concerns in the meantime. :slight_smile:

Best regards,

Kenny

4

To work around now, I actually have to

  1. Delete the Target
  2. Create a new Release (vNext)
  3. Deploy the Release
  4. Delete the previous Release (vOld)
  5. Delete the Account

The reason being that if (vOld) is just deleted, then the “New Healthy Target” trigger will attempt to deploy the most recent successful Release, which with vOld being deleted, will fallback to vEvenOlder that is likely an older package version or variable set.
By deploying a vNext after deleting the Target but before deleting the Release, I now have a safe Release for the Trigger to deploy. Of course, I need to make sure that all of the package versions and all of the variables of vNext are the same as vOld, which isn’t a straightforward process itself (package version can be visually verified to be the same, but what happens if there was a changed, but undeployed variable or library set value?). Ultimately, I just want to have the Release stick around, just not deploy to or reference the Target that no longer exists.

5

Ah, I re-read your reply. Deleting the deployment and then redeploying the Release may actually be a decent workaround for now. I’ll give that a try.

6

Confirmed that deleting the Deployment works. It’s better than needing to delete the whole Release, but still a pain to have to manually delete all deployments across all tenants across all projects that have a reference to that account.

7

Well, it partially works. Deleting the Deployment allows the Account to be deleted. But when a new Target is registered, the Trigger doesn’t end up deploying that Release to the new Target (I assume because there is no longer a successful Deployment of that Release).

8

Hi @rwkarg,

Thanks for following up with those additional helpful details. I’m still doing some investigation into this issue, though at the moment I think this is at least touching on this known bug: https://github.com/OctopusDeploy/Issues/issues/6390

If you have any questions or concerns as I continue looking into this one, please don’t hesitate to reach out!

Best regards,

Kenny

10

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.

11

Hi @rwkarg,

I just wanted to reach out again to firstly apologize for the long delay since I’ve given you an update, and secondly that I’ve raised this behavior as a bug report at the following link that you can track.

If you have any questions or concerns at all, please don’t hesitate to reach out!

Best regards,

Kenny