My configuration file
“Notification”: {
“PrivateKey”: “Octopus-Deployment-Variable”
}
Notification:PrivateKey value is set to “-----BEGIN PRIVATE KEY-----\nMIIaaafdff…\n-----END PRIVATE KEY-----” (as plain text)
After variable replacement, it added extra splash (escape character) as below
“Notification”: {
“PrivateKey”: “-----BEGIN PRIVATE KEY-----\\nMIIaaafdff…\\n-----END PRIVATE KEY-----”
}
Would you please let me know if I could turn off this feature (not escape this new line character) or workaround?
I’m sorry to hear you’re hitting this unexpected issue. It looks like your variable name and value are correctly defined and I haven’t had any luck in reproducing this behavior, so I don’t see any reason for this extra escape character in the result after substitution. Could you let me know which version specifically of Octopus you’re running so I can give it a go in the same version locally?
Thanks for the update! I still haven’t had luck reproducing this unexpected issue, strangely. While I continue looking at this, I imagine you’d be able to work around this by instead using standard variable substitution, though this would require some tweaks. You’d need to change the name of the variable, say PrivateKey, then update the JSON at the right place with the substitution syntax, e.g. “PrivateKey”: “#{PrivateKey}”, then enable the Substitute Variables in Files feature (recently renamed to Substitute Variables in Templates) on your package step while targeting the JSON file in that field.
I hope that helps for now, and I look forward to getting to the bottom of this one.
Thank for your response. I am just a novice in Octopus deploy. I’d like to give you a little bit more detail that what I am trying to do is to configure JSON file variable replacements in the appSettings.json file of ASP.net project.
Please also be informed when I try to change “Plain Text” to “C#”, the editor resets to “Plain Text” anytime I re-open it.
Thanks for following up! The Substitute variables in files feature can target any text file, including JSON files, so that should hopefully be a workaround for you for now. In my local testing the JSON variable substitution does not add the extra \ during the process, so your reported behavior is something I’d like to get to the bottom of, but hopefully that workaround helps for the time being.
Regarding the language selection being reset in the variable editor, this is something I’ve previously reproduced and raised a bug for at the following link.
If I recall, this bug is just in the UI where the language selection is used for highlighting around the specific language’s syntax, so it shouldn’t cause any issues beyond that.
