Leading space in variable content gets trimmed

Legacy Uncategorised
1

Scenario:
Using version: 2.6.0.778
A variable, lets call it EnvSuffix exists for each environment and will be appended to the end of another variable such as “myval#{EnvSuffix}”. Content of EnvSuffix is space, dash, sapce then the environment string. eg " - DEV"
This goes into the variable editor fine, but internally the variable content appears be being trimmed. When editing the variable again, the leading space is gone.
I attempted to set the variable content with the leading space, not editing it and creating and deploying a release in case it was a strange behavior of the editor. No dice :frowning: The result in the web.config file did not include the leading space either.

Is this a defined behavior? My searches came up dry. Is there a way to encode a space such that it decoedes properly in the resulting output?

2

Hi Ryan,

Thanks for getting in touch! This is unfortunately this is by design that we trim spaces from the front of variables. It is to do with bad copy and pasting reasons but tends to work out for majority.
I would suggest making the value of your first variable myval #{EnvSuffix} (the space is in this first variable instead).

I send this in haste, and have not tested it myself. Please let me know if that will work for you.
Vanessa

3

Thank you for your quick reply Vanessa,
Unfortunately that won’t work for our situation as is… one environment in the example will not have a suffix and a trailing space would result in an incorrect value, thus why I was including the space in the suffix. I do have a work around of creating each variable explicitly (multiplying the number of different variables by the environments).

My take-away request would be a way to signal to Octopus to not trim the front or a way to escape a space into the value such as “\ - DEV”.

Again, thank you for your quick response.
Ryan Brown,

4

Hi Ryan,

I have seen this come up before where it has caught out some customers who have wanted to rely on it. Unfortunately I think as there is a valid workaround it would be hard to get a priority on this as a fix. But I will keep it in mind if we get a bunch of similar reports to see about getting it into our backlog.

Vanessa