Unfortunately it’s not that simple - the Release only stores the version number of the package to be used in a step, and the package name and feed are saved with the process snapshot. So the package name in your case is ultimately a variable under the covers. It is a bit confusing so I’ll try to explain.
When you create a Release, Octopus will ask you for a package version for your package step. To help you choose a version number that will actually exist, it resolves the variable that’s being used for the package name (hidden behind a parameter in your case). But what’s actually stored in the Release is just the step name and the version number for that release.
It’s easier to see what’s going on if you use the API.
If you go to
api/releases/Releases-2), you can see a JSON representation of the object we store. To find the Release Id, you might need to look at the API calls in your browser dev tools. You’ll see in the
SelectedPackages property the only details we’re storing are the name of the step that needs a package, and the version to use.
In this JSON, look for the Links property. It will have a link to the
ProjectDeploymentProcessSnapshot. If you hit that endpoint, you can see the process as it will actually get run. If you find the correct
Action, you’ll see in
Properties that the
Octopus.Action.Package.NuGetPackageId will have the parameter name, not the hardcoded value you’ve given it. You should also be able to see the variable that’s behind the parameter and the value you provided directly in the step. Incidentally, the
ProjectVariableSnapshot property of the Release will give you the variable values that may override this variable during deployments.
The short version is the package name for a step template will be resolved each time it’s used. That means even though you chose the version number from
PackageA when you created the Release, you could have scoped variables that would change this value later on deployment to
PackageB. This is handy for people who want to deploy different packages to different environments.
How does this apply to retention? If a project has a step that defines a package Id with a variable (as will always be the case if you’re using a step template), we try to leave all of those packages alone. The reason is described fairly well in those threads you linked to, but it’s due to the above - that package name may change between environments, so we can’t easily evaluate whether the package being used in Test corresponds to the one that will be deployed in Production.
I understand in your case that you’re hard-coding that value and not changing it later on with variables, so it’s not ideal. However, the way this process currently works makes it very difficult to reason about the packages we need to keep.
I hope that helped explain! Let me know if anything’s not clear.