I’ve created an email template that contains an EmailCC parameter. As it stands, it appears that this is a required field in Octopus (which is annoying, but I can work with it), the problem is when I try and assign a variable set variable to it.
I have a variable set (let’s call it ‘Shared’) within it, I have a variable called Shared.EmailCC and I assign different addresses based on environment
now as I said, the local, dev email address is annoying, but I can live with it… please change to NOT required when you have a chance. But, what the issue is, is when I assign the variable to the parameter in the template. If I just assign it with #{Shared.EmailCC} the process with fail with the following error.
The parameter ‘addresses’ cannot be an empty string. Parameter name:
addresses System.ArgumentException: The parameter ‘addresses’ cannot
be an empty string. Parameter name: addresses at
System.Net.Mail.MailAddressCollection.Add(String addresses) at
Octopus.Server.Orchestration.Deploy.Email.EmailActionOrchestrator.CreateMessage(SmtpConfiguration
smtp, DeploymentAction action, IDeploymentManifest manifest) in
y:\work\refs\heads\master\source\Octopus.Server\Orchestration\Deploy\Email\EmailActionOrchestrator.cs:line
92 at
Octopus.Server.Orchestration.Deploy.Email.EmailActionOrchestrator.d__0.MoveNext()
in
y:\work\refs\heads\master\source\Octopus.Server\Orchestration\Deploy\Email\EmailActionOrchestrator.cs:line
48 Octopus.Server version 2.6.4.951 Fatal 12:45:31 The step failed
And in order to make it work properly, I have to prepend the parameter with a comma. , #{Shared.EmailCC}
I consider this a bug… pretty sure it can’t be “by design”.
Further to this, it would appear as though the “comma” work around only works when a deployment is created via the WebUI. If a deployment is created via octo.exe, I still get the same failing message above. If I “Try Again” to the same environment, via the webUI, the email comes through… again, this is only if I use the comma work around.
Can you provide your email step template, we are having a hard time replicating this. Also if you could include all screenshots of your variables for it, and the command line you are using.
Hi Vanessa, I feel terrible. It looks as though that bit was a red herring. It turns out that it was the fact that my orchestrator was using a service account that doesn’t have an email address.
I might be abusing octopus a little bit, but I’ve got it working.
Here’s a gist showing how teamcity creates a release/deployment, and how the orchestrator picks it up and carries on.
note how I grab the users email address (Get-LastCommitterEmail) and pass it as a variable to octo.exe
Then when the release is created, the orchestrator grabs that email and passes it along to each subsequent release.
Essentially, because it’s a service account doing all of the work, I needed a way to impersonate a specific user throughout the entire process.
All 6 apps implement the GCTS Shared variable set (screenshot below).
So, as I said, I might be abusing octopus a little in order to get it to bend to my will, but it is working. Is there a better way? One thing I know is that I don’t like using the “prompt” variable in order for octo.exe to be able to update it.
Well I am glad that you figured it out and got it working. I’ve closed off the issue in GitHub.
We have an API and octo.exe to allow people to ‘build their own’ but it does fall under ‘you can only do what its designed to do’ blanket.
In the UI when you want to change variables before a release you change variables and then create your release, prompted being the only type of variable that asks what value you want when the release is created.
I know customers who use the API to mimic these behaviors to update variables and then create the release.
