I noticed our retention policy cleanup is logging a lot of warnings & not removing old releases. We get heaps & heaps of this across many projects:
08:43:04 Warning | Error attempting to evaluate Package ID for action 'Deploy Dev' in release '2022.7.0-dev' of project 'Projects-81'. This may prevent unused packages from being deleted. Exception: An attempt to parse the variable symbol "ProjectName" appears to have resulted in a self referencing loop (ProjectName -> ProjectName). Ensure that recursive loops do not exist in the variable values.
If I go look at a release that should have gotten cleaned up & review the variable snapshot, it looks the way I expect for that variable:
I do see this warning in our deployment logs but it’s unclear why it’s able to resolve when doing a deploy but not when doing a cleanup:
You have defined variables either on this project or in a variable set used by this project that override the values entered in the setup of this step. The most likely cause is that you are using a step template that has variables with the same name in its definition. We recommend either adding a prefix to your step template variables, or changing the names of the variables on your project. The conflicting variables are 'ProjectName'. For more information, see https://g.octopushq.com/UserVariablesOverridingStepVariables.
To log this warning as verbose instead, add the 'OctopusSuppressDuplicateVariableWarning' variable to your project with a value of 'true'.
I realize we should add a prefix to the step variable but it’s been that way forever. Seems like if it works for the deploy, it should work for the cleanup?
Also, it’s unclear whether adding a prefix now will allow old releases to be cleaned up?
Hi @josh_centerx,
Thank you for contacting Octopus Support.
For Releases that are affected by the duplicate variables, you’ll need to delete them manually outside of the Apply retention policies task. You may do this via the UI or you can modify the script below if you are able to make a list of Release IDs that can help you do this via the API:
This is a script that deletes all releases for a project. Please be sure to modify for your needs. Do not run as is.
You could possibly update the Snapshot for each Release with the updated variable to then try retentions again. However, deleting the Releases and fixing this going forward is likely the most straightforward option.
If you have any additional questions, please let us know.
Best Regards,
Donny
OK, that’s at least an option.
I guess it’s not clear why the retention policy even cares about this? If the release exists & is older than the policy, why does it matter what the variables are? Just delete it & move on?
Hi @josh_centerx,
Thank you for the quick response.
The only reason I can think of that there is a difference is that we didn’t want block deployments, but wanted to encourage fixing the source of the duplicate variables.
If a Release is older than the applicable Retentions Policy settings, I would imagine you should be safe to delete. It might be a good idea to make a fresh Octopus db backup as a precaution.
Let us know if we can assist with anything else.
Best Regards,
Donny
I have a new/different flavor: I’m getting the “duplicate variable” error on a step that doesn’t have a template. What might cause that?
Here’s the error:
You have defined variables either on this project or in a variable set used by this project that override the values entered in the setup of this step. The most likely cause is that you are using a step template that has variables with the same name in its definition. We recommend either adding a prefix to your step template variables, or changing the names of the variables on your project. The conflicting variables are 'Container.Prefix'. For more information, see https://g.octopushq.com/UserVariablesOverridingStepVariables.
To log this warning as verbose instead, add the 'OctopusSuppressDuplicateVariableWarning' variable to your project with a value of 'true'.
September 21st 2022 10:30:20
Warning
You have defined variables either on this project or in a variable set used by this project that override the values entered in the setup of this step. The most likely cause is that you are using a step template that has variables with the same name in its definition. We recommend either adding a prefix to your step template variables, or changing the names of the variables on your project. The conflicting variables are 'Container.Prefix'. For more information, see https://g.octopushq.com/UserVariablesOverridingStepVariables.
To log this warning as verbose instead, add the 'OctopusSuppressDuplicateVariableWarning' variable to your project with a value of 'true'.
Hey @josh_centerx,
You might see that error on any snapshot that contains duplicate variable values. Are you using a library variable set in that project? You may have variables that share the same name in the library set and at the project level. You’ll likely see those warnings until the duplicate variable names are changed.
Best,
Brent
I’m not sure I follow the logic… Adding a project-level variable that shares the same name as a library variable is the way to override a variable at the project level?
Regardless, it’s not that for this variable… It’s only got a single value:
Hey @josh_centerx,
I’m betting that the error is likely due to that variable value being a reference to two other variables. Is one of those variable names used in a step template for that project?
If you’re fine with the duplicate names and just want retention to work correctly, you may be able to set that OctopusSuppressDuplicateVariableWarning value to true and see if the retention functions properly without those warnings appearing.
Best,
Brent
We use the same Container.Prefix variable on multiple steps. Only some of the steps throw warnings. None of the steps that reference the variable have step templates.
You say, " you may be able to set that OctopusSuppressDuplicateVariableWarning value to true and see if the retention functions properly without those warnings appearing". Is there a way you can confirm this is indeed how it works? Is it retroactive or only applies to releases created going forward? It doesn’t offer much reassurance the way it works or is intended base on what you’ve said.
Hey @josh_centerx,
That variable change would only apply to new releases. I don’t know for sure if the use of that variable would affect the retention policy’s ability to remove future releases, but it’s something you could try while we work to determine what is causing those warnings. I may need to ask our engineering team to review this to see if they might be able to find the cause. Would you be able to send a process step JSON export for that project?
That info would help us get the full picture of what it taking place in your deployment process and hopefully help us determine the cause of the warnings.
Best,
Brent
Do you have a spot I can upload the file to that’s not public?
Absolutely, you can use our secure upload link, authorized for your email only here - Support - Octopus Deploy
Best,
Brent
Thanks @josh_centerx.
One other ask. Can you send us a task log with variable logging enabled? I think with that and with the process JSON, we should be able to determine what is happening.
Can you also send a recent retention policy run so we can compare that as well?
You can use the same upload link to add those additional files.
Thanks,
Brent
I’ve uploaded a recent retention run. Unfortunately, the project that I cited with the Container.Prefix duplicate warning hasn’t reached our retention limit (365 days).
For the other projects with confirmed duplicate variables related to Project.Name, we have updated our step to change the overlap but we haven’t gone back & cleaned up the old releases yet.
Working on the run with variable logging.
I’ve uploaded a deploy run with the variable logging settings turned on.
Excellent, thanks @josh_centerx,
I will review and engage with our engineering team and get back to you when I have an update.
Cheers,
Brent
Hey @josh_centerx,
Thanks for your patience while engineering reviewed the info you sent over. The good news is engineering thinks they know what is causing that duplicate variable error.
They think the problem step originally had these steps deriving from a step template with a parameter called Container.Prefix . Then the step was detached from the template, and when that happened, those properties hung around on the step. Octopus then sees them as a system-Variable, which is why the phantom conflict warning.
Our engineering team confirmed this suspicion by performing a reproduction using those steps and experienced the same outcome. The solution is to either delete and recreate the step, or make an API call to the Process endpoint, removing those non-Octopus-Prefixed properties from your process.
Thanks again for your patience while we worked through this. Let us know if you have any other questions.
Best,
Brent
Ah, that’s quite possibly the case… Is there possibly going to be a fix to remove those phantom variables when detaching a step template in the future? I realize doing a cleanup action from your end is probably not a high priority but it would be nice to prevent this for others going forward. If not, I guess the answer is to just never detach a template & just delete & create new.
If memory serves, we copied the project from an older project in order to implement tenants. But the step from the template had something wonky, so we detached it so as to not impact the older project.
This will hopefully be a lot simpler once we’re able to implement CaC…
Hey @josh_centerx,
Engineering told me they would evaluate that possibility, but I’m not sure if it will make it to their backlog soon as they’ve got a lot slated for development in Q4 and Q1 next year. For now, the best recommendation would probably be to delete and re-create the step.
Best,
Brent
