I’m passing a variable as follows #{Octopus.Release.Number } . When the release number ends in zero, i.e. 20008.10, the value that gets passed is 20008.1, which causes errors downstream. I’ve tried #{Octopus.Release.Number | Format “00000.00”} but the trailing zero is still dropped. How can I ensure the trailing zero is not dropped?
Hi Bob,
Thanks for getting in touch! That’s very strange, and certainly incorrect behavior. I’ve given this a quick test with a script step writing the #{Octopus.Release.Number} variable, and defining the release number as 20008.10 like you’ve done, and the result is correct (i.e. the trailing zero is not dropped).
How are you performing the substitution? Can you also let me know which version of Octopus you’re running, and send through a copy of your verbose task log with debugging variables enabled? These debugging variables will write out every variable available at the beginning of each step, and what they evaluate into, which should shed more light on this. The following doc page outlines how to produce and export this verbose log.
I look forward to hearing back and getting to the bottom of this one!
Best regards,
Kenny
Hi Kenny, thanks for getting back with me. Our situation is very specific. This happens in the “UPGRADE A HELM CHART” process step. See attached. Our Octopus version is: V2019.6.7 LTS
I’ve tried using the variable filter, like #{Octopus.Release.Number | Format N2} , but I can’t find a format that simply turns the decimal number into a string.
I can work on getting you the verbose log tomorrow. It’s 10 PM in Austin, TX 
Hi Bob,
Thanks for keeping in touch! The #{Octopus.Release.Number} system variable should still populate as expected in this step type, and as far as I’m aware nothing about this step should be trimming off the trailing zero, so this is mysterious. A verbose task log taken from a deployment which reproduced this will give us the most information.
Note that applying the debugging variables (OctopusPrintVariables and OctopusPrintEvaluatedVariables, both with a value of True) will require a new release to be created (with another trailing zero to reproduce the issue).
I look forward to hearing back!
Best regards,
Kenny
Hi Kenny, I’ve attached the verbose log and a screenshot of the kubernetes dashboard showing the error where the trailing zero is dropped. However, the log shows the Octopus is passing the full number. At this point, I believe the problem lies with the attribute declaration in the Helm chart or with Helm. Give me a couple days, and I’ll update the ticket in that regard. Thanks for your quick and helpful response! Bob
ServerTasks-2690925.log.txt (60.5 KB)
Ok Kenny, I found a work around. It looks to be a bug with Helm. I did two things:
- I changed the declaration of the version number in the helm chart from:
version: 0.1.4toversion: "0.1.4". This by itself made no difference, and it may not be needed as the second action alone might be sufficient to prevent the problem - I created the following Octopus project variable (see image) that had a trailing space. This was passed to helm which forced helm to interpret the value as a string. The trailing space was then ignored when looking up the docker image and voila
Unfortunately, that broke something down stream in the helm deployment. But at least the image tag value was correct 
Hi Bob,
Thanks for keeping me up to date, and great to hear it seems like you’ve been able to make some progress! Is the part that broke downstream something I can try to help with? Feel free to elaborate a bit on the current state of this, and I’ll be more than happy to help in any way I can.
Best regards,
Kenny