Is it possible to set a value within one PowerShell step, and then read the same value out in a different steps (in particular e-mail step)?
For example, I created a variable with no scope set and therefore should be available to read from all steps within a project/deployment. I need to set the value for the variable within one of the steps and to be able to read the value from any other step within the project/deployment. A specific example of this usage is for a release name, which is set during deployment and should remain unchanged throughout the entire deployment. The release name is stored within the deployment package and has to be read from the package using PowerShell. The value is then available to other steps.
I can almost achieve the desired outcome as follows:
Extract the value from the variable collection within the package deployment step.
Set the variable using the Set-OctopusVariable PowerShell command.
Read the variable value in other steps.
However, when a use an E-mail step, the variable is empty.
Thanks for reaching out! The steps you are following should be working for email steps as well
1. Extract the value from the variable collection within the package deployment step. 2. Set the variable using the Set-OctopusVariable PowerShell command.
3. Read the variable value in other steps.
Can you give me the exact set-octopusvariable command you are running, along with the text in your email file where you are referencing the variable? I’d like to give that a try myself.
Also please let me know which version of Octopus you are running.
The PowerShell command resides within the Module Library and is invoked
from the “Pre-Deployment Script” for a Azure Cloud Service deployment step:
Set-OctopusVariable -name “ReleaseName” -value $releaseName
The variable does seem to be set and I can reads it’s value from other
Azure PowerShell steps. However, when I use #{ReleaseName} in either the
Subject or Body of the e-mail step, it is blank.
Whilst I appreciate this is a solution, I do not feel as though it is
satisfactory one. Hard coding step names (which are very likely to change
at any point) into scripts will undoubtedly lead to deployments failing in
future.
I do understand your feelings about this approach. We’ve had a couple of users in the past that shared the same opinion which triggered an informal discussion on the team about the subject.
I brought this discussion back on the team in a (sort of) more formal way, and we agreed to create a Uservoice suggestion for this where we shared our thoughts on the matter, and encourage other users to do the same while dropping some votes.