I'm still wondering if this is ever going to be addressed? It's bitten me again today.

Just thought I would post the ugly that this causes. My steps have to have this as the "Notes":
---------

DO NOT CHANGE THE STEP NAME!

If you must, then you need to update the Helm Chart, the Team City scripts and the embedded PowerShell scripts for this step to use the new step name in the variable references.
---------

At the very least, the Octopus UI should warn the user that changing the name may break scripts that reference variables created in that step. Maybe only show it if there are scripts enabled for the step at at least one of them contains the text "Set-OctopusVariable" (or equivalent for other languages).

This is a big issue when building templates for other users. They don't know that they can't just change the name of the step to fit what they are doing.

I don't understand why I can't just add a project level variable. None of this "Octopus.Action[StepOne].Output.TestResult" business. When I call Set-OctopusVariable -name "TestResult" -value "Passed" then I should be able to get at that with #{TestResult}

If it conflicts with an existing project level variable, then throw an error and fail the deployment (or just overwrite the value.)

That way if I want my Output variable to be step step specific, I can add it to the name of the variable I am creating. For example #{StepOneTestResult}

I've hit this problem several times in the past and again today. The suggestion has a good number of votes, is it every going to be addressed?

I have another alternative approach: Step alias names.

Imagine:
StepA sets a variable "MyVariable".
StepA also gets assigned an arbitrary alias name, say "AliasMyVariable".
For some reason StepA gets renamed to StepB. Since it still has the AliasMyVariable alias, references to it are still valid.
For some reason we have to set MyVariable on StepC instead of StepA. We just remove the AliasMyVariable alias from StepA and assign it to StepC. (The use of a GUID for the step doesn't address this situation.)
A step template has to reference MyVariable no matter where it's used. Just assign the AliasMyVariable to the appropriate step and the step template works.

Today I ran into same issue, in a big long running deployment process flow I renamed a step and it broke the process as I did not change it at other places. This is really painful.

For me the issue is having to update code if a step name changes. On occasion, the person updating the Octopus process doesn't have access to the code, and another person has to become involved. It's also pretty easy to overlook having to update code when changing something in Octopus.

Personally I wouldn't be bothered by having to access an output variable using a GUID. We already have to use a GUID for setting variable values when deploying a release through the API, so there is precedent to use the GUID.

Is there any reason why `Set-OctopusVariable` can't output multiple output variables, giving the user the option to reference the output variable in the way that suits them?

1. Original -
$OctopusParameters["Octopus.Action[Step Name].Output.VariableName"]
2. Using step GUID -
$OctopusParameters["Octopus.ActionFromId[08c21caa-123f-4853-8b11-3797340ac977].Output.VariableName"]
3. As suggested by William Steinford -
$OctopusParameters["Octopus.Output.VariableName"]

I agree with William. Why even use steps to identify the variables. You should be able to reference a variable from any step just by variable name. Just like you are able to reference project variables.

I suggest that the VariableName should be considered as definitive... Forget about referencing the step at all. If we cared to receive different variables from different steps, they'd be given different names.

If multiple steps change the same variable, then, Great! That's how variables work everywhere else! It also prevents a step from referencing an output variable from a future step that hasn't executed yet... Why does the syntax currently permit "peering into the future"?

When a variable is referenced, the value should be whatever the *current* value is.

This permits using the simple and obvious syntax like:
$OctopusParameters["Octopus.Output.VariableName"]

Another approach would be to allow the steps to modify Tenant variables and persist those values (if they're configured to be modifiable). Then, each step could just change the value using Set-OctopusVariable, and the variable could be referenced like $OctopusParameters["VariableName"]. This would also permit a deployment to store some kind of state that could influence future deployments.

Both approaches could remain backward-compatible by allowing the old, odd syntax that requires referencing the step name. That would maintain the possibility of examining the output value from a specific step if there's ever any need to.

I ran into this today - renamed a step and then the variable referencing it in a subsequent step was out of date. The next deploy didn't even fail so it took a while to track down!