Retention Policies and the Deploy a Release step

Legacy Execution
1

I’ve run into an issue using the “Deploy a Release” step and retention policies. This is the scenario:

  1. “Project A” has a deploy a release step to deploy “Project B”, both with release number “1.2.3”
  2. Project B has a different retention policy, and has release 1.2.3 deleted
  3. Project A now has a release that cannot be deployed, as it references a non-existent release of Project B.

I was under the impression that because the release of Project A references the release of Project B, it would be kept, just like the retention policy keeps packages referenced by releases. They currently use different retention policies as Project B is actually a shared project used by many different projects. Is this a bug? If not, is there a workaround other than setting Project B to “Keep forever” and manually cleaning up releases?

2

Hi Chris,
Thanks for reaching out, I have had a chat with the team and we agree this is a bug. I have raised an issue for it here so you can keep an eye on it. hopefully we will get a fix out for it in the near future.

I hope that helps, please let me know if you have any further questions.

Kind regards,
Tom W

3

Hey Tom,

I’ll follow the issue status there. Thank you very much for the quick turnaround and discussion.

-Chris