Variable with value of null being deployed as "null"

Hey,

We have 2 variables of Variable Type Text and I guess string type Plain Text from looking at the Editor window.

When it’s deployed the config turns from null to “null”
Here’s the RAW log output… we have tried deleting, saving, re-adding and deploying again but no joy.

15:10:07   Verbose  |       Structure found matching the variable 'MerchantPortalWebSite:EMail:SenderEMailAddress'. Replacing its content with the variable value.
15:10:07   Verbose  |       Structure found matching the variable 'MerchantPortalWebSite:EMail:SenderPassword'. Replacing its content with the variable value.

Any help would be appreciated.
Thanks

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:

image

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

Hi Patrick,

Thanks for your response.

Yes the variable has a string value of null but when deployed OD is changing it to “null”

image

I have just tried option 1 and 2 as they were easiest and required no code changes from our DEVs but sadly neither worked.

image

Iain

Hi Iain,

Thanks for getting back to me and sorry to hear those Options 1 and 2 aren’t working for you.

I can’t seem to reproduce the issue regarding Option 1, so I was wondering if you’d be willing to provide me with a raw Task log with Variable Logging enabled so I can see how this variable is being evaluated/scoped in your deployment? You can use the following link to send this to me securely:

cs-admin | Octopus Support

Regarding Option 2, it looks like there is most likely a bug here with how the initial value of a variable is handled, but I’m currently investigating this and will get back to you when I know more.

If you’re unable to get either of these Options working, the surefire way to work around this in the meantime is to use Option 4. This shouldn’t involve too much extra work, and the following StackOverflow article may be helpful in showing how this can be done: How can I replace every occurrence of a String in a file with PowerShell? - Stack Overflow

Let me know what you think, and I’ll keep you updated with what I find on my end.

Best regards,
Patrick

Hi Patrick,

Option 2 actually worked I just didn’t realise it.
Didn’t enter any value for the variable and it was deployed as “SenderEMailAddress”: “”,

Which worked with our SMTP relay.

Thanks for all your help,
Iain

2 Likes

Uploaded RAW logs too so you can see what’s happening.

2 Likes

Hey @cs-admin

Just jumping in for Patrick who is currently offline as part of our US based support team, I was actually testing this last night with another one of our support staff and they then did the handover with Patrick when he came online later that night.

I also tried Option 2 and if I put a value of null for my variable in the .json file and had the variable in Octopus set to no value, on deployment Octopus changed that value to "" in the config file.

Config file before the variable substitution:

image

Variable in Octopus without a value:

Config file after variable substitution:

image

We assumed this is not what you wanted since "" is still a string and is technically not a correct null value, are you saying that does work as intended then, from your previous answer it seems like this works for you and you are happy Option 2 is what you will use in future if you wanted to repeat this for another project?

If so that’s great we can close our discussions off our end but if you did need a correct null value we can do some more digging into this.

Kind Regards,
Clare

1 Like

Hi Clare,

null or “” works with our SMTP just not “null” so from our end, we are sorted using Option 2 and this thread can be closed.

Thanks
Iain

3 Likes

Hey @cs-admin,

Great news thank you for confirming that, I will take this back to everyone that worked on it so they are aware.

If you need anything in future please reach out as we are always on hand to help,

Kind Regards and Happy Deployments,
Clare

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.