After upgrade to 3.0.1 deployment failed with the following exception.
Could not find certificate under Cert:\LocalMachine with thumbprint #{SSL thumbprint}. Make sure that the certificate is installed to the Local Machine context and that the private key is available.
Nothing was changed at the variables or on the server side.
I was able to resolve it by renaming #{SSL thumbprint} -> #{SSLThumbprint} (removed the space).
I am not sure if that was the fix, or maybe the fact that new variable was renamed or task was saved, or maybe a combination of both
Thanks for the report. I have created a ticket for us to investigate where the missing space went.
Can you confirm for me that it was part of a variable set and that it was your only variable with a space?
Evgeny,
I have set up a 2.6 build with a variable that has a space in the name called SSL thumbprint (sceenshot #1). I then created a 3.0 install and imported this backup and the variable appears to have come across fine (screenshot #2).
After running a PowerShell task calling Write-Host $OctopusParameters["SSL thumbprint"] I could see the variable correctly getting printed to output. So far the import process looks to have worked correctly and preserved the name.
Looking through the migration code I couldn’t see how\where it would be getting the space removed.
Could you confirm if this matches the scenario you have encountered in which the space was removed? Was the variable perhaps renamed at some point?
Thanks,
Rob
Hi and sorry for the late response (to Vanessa’s post).
Couple of comments:
Variable “SSL thumbprint” was in the Variable set.
There were quite a few other variables with the spaces at the same Variable set and all of them were properly used at the same release during config file transformation (see image attached)
The “SSL thumbprint” variable was used and wasn’t found within “IIS binding” context and I think this is important
I had the same issue. In 2.6 I had a lot of variables with spaces in names. They were used in custom installation directory, IIS binding etc. But after upgrading to 3.0 all my deployment failed. After i change all variables name (delete spaces) everything become OK.
I am hitting this issue as well, on variables for a process. All of our projects (60ish) use variables with spaces in them. I fixed one variable to not have a space and it failed on another.
In the task log you can see the variable not being replaced:
Checking if server #{F5 ServerName} is the active...
If I look in the database, it looks like the spaces are there just fine :
Addendum, I looked in the database and the spaces are still there. Removing the space in the variable edit screen and adding it back still do not allow it to work, it’s almost like the issue is in the variable replacement code.
Hi guys,
Thanks for all getting back to me so quick. Ill take another look and focus on the variable replacement process.
Will let you know what we find!
Cheers,
Rob
I’ll also add that we hit this issue after upgrading to 3.0. Removing the spaces from the variable that had spaces in it fixed the issue.
The variable was being passed in as a custom parameter to a custom step template but it wasn’t being replaced with the actual value of the variable when passed to the powershell script. Instead it was getting the text #{My Variable With Spaces}. So I agree the variable replacement looks like the culprit.
Hi all again
After some investigation it turns out there was a bug in Octostache that meant it would not parse spaces in variable names during variable replacement.
As noted in the ticket posted by Vanesssa above, this has since been fixed and the new version of Octostache has been pulled into Octopus Deploy to be released as part of the next 3.0.5 release.
Thanks to everyone for providing some background to this issue and
keep your eye out for the release in the next day or two to get your variables with spaces working again!
Cheers,
Rob
