since upgrading from 2019.3.5 to 2019.6.0 email step templates have broken for us
I have been unable to figure out what has changed to cause our step templates start failing. The error we get is:
Could not replace variables in the email body: The following tokens were unable to be evaluated: ‘#{Octopus.Tentacle.PreviousInstallation.PackageVersion}’, ‘#{Octopus.Machine.Name}’, ‘#{Octopus.Machine.Hostname}’
The subject we have is:
#{Octopus.Project.Name} v#{Octopus.Release.Number} Deployed to #{Octopus.Environment.Name}#{if Octopus.Deployment.Error} (Deployment Failed)#{/if}
The body is:
A deployment was done by: #{Octopus.Deployment.CreatedBy.DisplayName} - #{Octopus.Deployment.CreatedBy.Username}
Deployment id is #{Octopus.Deployment.Id}
#{if Octopus.Deployment.Error}
Error: #{Octopus.Deployment.Error}
#{/if}
Previous successful deployment was #{Octopus.Deployment.PreviousSuccessful.Id}
Specifc machines are #{Octopus.Deployment.SpecificMachines}
#{Octopus.Deployment.CreatedBy.Username}
Since the error message is only listing 3 variables it suggests to me some scoping or permissioning or variable naming has changed, but I have been unable to locate anything in the release notes that would explain this or help me figure out what I should change these variables to.
Thanks for getting in touch! I’m sorry to hear you’re hitting this trouble. I started putting in some time mimicking your setup and tweaking the subject and body (thanks for that helpful info by the way!), though another important factor is if your email step is a standalone step or a child step. Can you confirm this aspect of your setup?
I ask as these machine variables are only able to resolve to their respective values on the step it’s currently running on, and the email step essentially runs just once on the Octopus server. A potential workaround to this behavior could be to create an output variable inside the step you need to capture the machine variables from.
For example, Set-OctopusVariable -name "machinename" -value #{Octopus.Machine.Name} then call this output variable in your email step with #{Octopus.Action[StepName}.Output.machinename}.
Additionally, if you’re still hitting this issue a deployment log with debugging variables enabled might help going forward as well. The process to produce and export this log is outlined in the following doc page.
The step is a standalone step. So if I understand your comments correctly this means that I would either need to change the email step as a child step or to pass the variables down from the step(s) before to capture the machine variables. What I don’t understand is how would this have ever worked? Was there a change between 2019.3.5 to 2019.6.0 that explains this?
Changing the deployment process is going to be pretty tricky for us as we have > 100 projects that
Before I do anything else I am going to turn on variable logging to see what it I can see.
Adding the variable logging didnt show anything for the emailing step
It feels to me like I am not going to get this working with the 3 missing variables because whatever has changed recently has made it impossible to get the values out of the previous steps
the solution of passing the variables doesn’t really work for us because we have many deployments that have more than one deployment step before the email step so we would have to work really hard to make that happen.
I think the easiest solution here is to abandon this whole approach and just use subscriptions.
Thanks for following up! That is a bit strange that this worked in your previous version, as I can’t spot any change that’s been made that explains why this behavior would be different now. After some further testing, I’m having a bit of a tough time sorting out a good solution here.
I do like your idea of implementing subscriptions in place of this. I imagine that would be a much easier approach, and would allow you to avoid having to update many deployment processes whenever a change is needing to be made.
However if you’re still wanting to make some use out of the email steps, I’ll be happy to re-address this and try to get to a better solution.
Hi Kenny, thank you for your help. I think for now we will just remove these variables from our email template with the view that we will make the move to subscriptions as soon as convenient.
