Skip to content

Settings and activity

3 results found

  1. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Product Feedback » Installation  ·  Flag idea as inappropriate…  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    William Steinford supported this idea  · 
  2. 20 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Product Feedback » Deployments  ·  Flag idea as inappropriate…  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    William Steinford supported this idea  · 
  3. 43 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    10 comments  ·  Product Feedback  ·  Flag idea as inappropriate…  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    William Steinford supported this idea  · 
    An error occurred while saving the comment
    William Steinford commented  · 

    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.