Hey @cs-admin,
Thanks for posting your issue and welcome to the community!
I just want to make sure I understand your configuration here and what you’re expecting. You’re using Structured Configuration Variables (e.g. MerchantPortalWebSite:EMail:SenderEMailAddress) and you’re setting the string Value of those to ‘null’ in Octopus. When the variable replacement occurs during your deployment, you’re expecting null or "" to be the value but instead, this comes out as "null"?
If that sounds right, then unfortunately, once a Value is set for a Variable in Octopus it loses its true null Value and will be replaced as a string Value. I understand this can lead to usability issues, but there are a few options to work around this limitation and hopefully one or a combination of these will work for you:
Option 1 - Set the default value of the variable to null or "" in your configuration file and scope the variable out of your deployment (e.g. by environment, tenant, etc) so that replacement doesn’t occur.
Option 2 - Use a blank Value for the variable. You can ‘reset’ a variable to null by adding a new Value and not entering any text, then removing the original Value:
These Values could also be Scoped individually if you would like more flexibility. It’s also possible to set a variable value to a true null using a REST API call, but that’s a little a lot of effort for this so I won’t go further into it unless you think it’s worth visiting.
Option 3 - Replace the entire block in your configuration file. If you’re able to isolate these variables in a section, you could use a higher-level structure as your Variable. As an example my configuration section would look like this:
{
"weatherApi": {
"url": "test.weather.com",
"key": "TEST7654321",
"enabled": false
}
}
In Octopus, the Variable and Value would look something like this:
The #{TestWeather} string for the url parameter is just to demonstrate Octopus variables will work, so I’ve used the following for it in Octopus:
Once the deployment has run, the configuration file looks like the following, with the null kept in place:
{ "weatherApi": {
"url": "test.newweather.com",
"key": "TEST7654321",
"enabled": null
}
}
So although you’ll have to likely create a few variable values of blocks like these to account for the ‘null’ and scope them as needed, you should be able to use Octopus variables to simplify this.
Option 4 - Run a post-deployment script to perform a find replace of "null" and change it to null within your configuration file . Unfortunately, I don’t have an example of this but you could either use the Custom Deployment Script feature of your deployment step (if your step has this feature) or use a Run a Script step after the package is deployed and target the package.
I hope that helps with a workaround, but let me know if you have any questions about the above or additional thoughts.
Best,
Patrick
