Our Octopus install started life as a Red Gate Deployment Manager install; we migrated from that, to Octopus 2.x, and then upwards to 3.0. As part of that, the “Legacy Variable Mappings” variable set in our install ended up including variables to allow our existing scripts referencing Red Gate variable names to continue functioning.
After upgrading from 2018.1.5 to 2018.10.2 LTS, those are now missing from the variable set.
I see a Script0129RepairLegacyLibraryVariableSet table in the database that contains the old variable set JSON, so we can at least rescue those values. But I would have expected them to still be included after the upgrade.
It looks like the UI now lets me update the Legacy Variable Mappings library variable set. Which is good, because now I can fix it that way instead of touching the JSON - but I don’t think it used to do that. That seems like an issue if upgrades are going to be blowing away the contents.
I haven’t tested this out, but it looks like the OctopusPackageNameAndVersion variable is now double-escaped - the new value is #{#{Octopus.Action.Package.NuGetPackageId}.#{Octopus.Action.Package.NuGetPackageVersion}}, compared to the old value of #{Octopus.Action.Package.NuGetPackageId}.#{Octopus.Action.Package.NuGetPackageVersion}. Is that intentional?
Thanks for getting in touch. Sorry about any disruption this has caused you.
When you say:
But I would have expected them to still be included after the upgrade.
Do you mean you have further variables in the legacy set, or other variables sets were impacted? Or is the Legacy Variable Mappings/Octopus 1.6 Variable Mappings set empty? (note it has different names for different customers depending on how they upgraded)
We had the understanding the set would be limited to the following variables:
OctopusEnvironmentName
OctopusMachineName
OctopusReleaseNumber
OctopusPackageName
OctopusPackageVersion
OctopusPackageNameAndVersion
OctopusProjectName
OctopusTaskId
OctopusProjectWebLink
OctopusReleaseWebLink
OctopusWebSiteName
OctopusDeploymentWebLink
These Legacy Variable Mappings were unknown to us until a few months ago. They’re a concept from over 5 years ago to support customers moving from Red Gate Deployment Manager to Octopus Deploy. We discovered through customer reports when some orphan-data cleanup code deleted them for some customers. It deleted them because the legacy data wasn’t in a structure/format known to the current logic inside Octopus which caused us migration script problems.
Because there was some unknowns we took some steps to preserve data that may need to be recovered and that’s what you see inside Script0129RepairLegacyLibraryVariableSet is all that we could capture.
Our intention was to have a new legacy library variable set created as standard set so it would be treated like all customer library variable sets. This is why it’s editable. Also it’s no longer a special concept. Making it a regular set ensure they are not manipulated unknowingly by future upgrade scripts.
Is it possible for you to move away from using that set and making your own library variable set with the values you need?
Then deleting the one we have created? We only created it for customers where we detected snap shots still using it. If you don’t need to deploy old releases, you will be able to adjust release retention policies. That way if you can’t delete the set soon, you will hopefully be able to delete it after some time that the old releases are no longer retained.
For item 3, I’m sorry this that double escaping is an oversight/bug from us. In the existing set or the new replace variable set, you can correct it to #{Octopus.Action.Package.NuGetPackageId}.#{Octopus.Action.Package.NuGetPackageVersion}?
Let me know if you need further help getting your library variable sets corrected.
This is another report of that same issue with the orphan data cleanup, then. I searched the forums but didn’t see anything already posted.
Our retention policies are currently set to keep all of our deployment history. Not because we expect to redeploy them, but because we want the logs. However, that won’t stop us from removing the variable set; as soon it’s no longer in the process for new releases it can be removed, even if the older releases are still retained. (We were already able to do that for a different variable set that we no longer use.) So I’ll look into removing our dependency on that variable set.
Meanwhile, I’ll update that one value in the set. Thanks!
