We have a variable in a json file set up like this: #{sqlsvr.#{service.name}.readwritepwd
When the transformation takes place on the server by looking in the extract folder for the package I can see the transformed value is this: #{sqlsvr.customeraccount.readwritepwd}
I can confirm that a variable lookup exists for #{sqlsvr.customeraccount.readwritepwd} as when I do a “preview” in the variables section for the project, a value correctly appears. It would expect this instead to be the variable lookup value for #{sqlsvr.customeraccount.readwritepwd}.
It appears that Octopus is performing the first lookup to convert the variable but then not doing the subsequent lookup with the “new” variable to get the final value.
I know this used to work. Has something changed in variable resolution syntax in Octopus?
Thanks for getting in touch! I’m sorry about the confusing behavior here. Which version was it working on? I’d like to give it a test in that version to see the difference in behavior.
I’m experiencing the same behavior in my local instance (2018.8.10) where the variable ends up as #{sqlsvr.customeraccount.readwritepwd} after substitution when I have a matching project variable. I achieved a workaround by adding another dummy package step with substitute variables in files feature enabled to target the same file. This allowed that variable to be substituted as was the initial expected result. Would that work for the time being?
Alternatively, you can use a dummy script step and enable the substitution feature and target this file, using the system variable to find the installation directory: #{Octopus.Action[PackageStep].Output.Package.InstallationDirectoryPath}\filestosubstitute.txt
I look forward to hearing back and getting to the bottom of this one.
Hi, unfortunately I’m not sure what the version was… it was a 2018.x series I did an upgrade to fix another issue so didn’t pay much attention to the older version. I can’t find anything in the audit logs about updates… does it get recorded in that?
Thanks for following up! Upgrades to the Octopus server aren’t recorded in the audit log, but it’ll be recorded in the server logs (located in C:\Octopus\Logs in standard installations), but may require some digging to find. I’d be very keen to confirm if this is a regression and when it happened based on the version you were on, but I can also test it in the first 2018.x release if needed.
Does targeting this file again in a subsequent step (which you can configure in a script step from 2018.8.0) help get around this for the time being? From my testing this will then transform the #{sqlsvr.customeraccount.readwritepwd} that’s left after the first substitution.
Unfortunately we only have logs going back 7 days. I’d be ok with knowing the latest version has fixed this (2018.9.3) but I’m not upgrading if it’s not needed.
I don’t wish to change my deployment script just for this… I’ve hacked the target file that being transformed instead; easier and safer than changing the Octopus script.
Thanks for following up and letting me know that you’ve worked around this for the time being. We’re currently still looking into this, and if it is in fact a regression, however we’re still unable to reproduce this in a few different 2018.x versions. This should be evaluating nested variables like you were attempting, and I’ll let you know any updates as we continue looking into it.
I did an upgrade to fix another issue so didn’t pay much attention to the older version. I can’t find anything in the audit logs about updates… does it get recorded in that?