I had a variable name for substitution that had dashes (-) in it and it failed to substitute.
The error message wasn’t clear thought about the real problem.
The only thing I could see was the dashes and it turned out it was the problem.
What are the illegal characters for a variable name?
Thanks for getting in touch!
The only legal characters for a variable exist in the set: a-zA-Z0-9:_
Anything else would really get in the way of being able to properly script the variables.
However we do not force this in the naming, and some people might have characters outside of this set working.
If you could provide the deployment log with the error, we can definitely look at making it more informative and also look at updating some of the documentation around variable names.
You say the following: “The only legal characters for a variable exist in the set: a-zA-Z0-9:_ “
But you forgot to mention the dot “.”, which is what I replaced the evil dash with.
You say the following: “Anything else would really get in the way of being able to properly script the variables. “
So basically, if I understand correctly, whatever character is legal in a variable name in a PowerShell script is good, right?
You say the following: “However we do not force this in the naming, and some people might have characters outside of this set working.”
But you could document clearly what characters are legal and that the use of others is hazardous and not recommended and explain why.
As of the error message I got, although it might appear that some characters are missing in the message (umbprint=), the following is exactly the complete message in the “Substitute variables in ServiceConfiguration.Cloud.cscfg” part of the step.:
The file contents could not be parsed as a valid Octopus template: Parsing failure: unexpected ‘#’; expected end of input (Line 19, Column 62); recently consumed: umbprint="
The line 19 is the following, column 62 is the hash sign, it comes from the ServiceConfiguration.Cloud.cscfg includes in the nuget package:
Yeah I said a few things in a specific way because we decided in the end to do this:
We are looking at setting a full limit of characters, and it is going to be a breaking change for those who have been able to use variable names with characters outside of these limits.
One thing you say below ‘whatever character is legal in a variable name in a PowerShell script is good, right’ is not exactly right, because we also use variables outside of just PowerShell scripts, in transforms and configs etc so what might be valid for PowerShell might not be valid elsewhere.
And thanks for supplying the error message and the feedback!
Vanessa, would it be possible for you guys to put a tooltip or other in Octopus wherever you create a variable (project or sets)? Perhaps a tooltip that tells you that you can use any variable name you want, but to be completely compatible please use only these characters?
I had all of my variable sets use a dot. “AmazonS3.Bucket”, however that blew up when I used variable substitution in a file. I had to go back through and rename all of them to “AmazonS3-Bucket” for example. Thoughts?
Dot’s should work. Well we think they should - any chance you could throw a screenshot or sample together to show us how the variable was used in your substitution file (and how it blew up).
I will then add it to the ticket and or create a new one. Sounds buggy.
The error messages when this is implemented should help a bit when naming variables. There will also be a supporting documentation page.