Overriding A Task Variable From Within A Task

[prodigy-byron-jones]

This may be a silly question, but I can't seem to glean the answer from the docs and would greatly appreciate the clarity.

I find myself not understanding how to programmatically update a Task variable from within a Task. This results in scenarios where I have to cast the variable to an ordinary bash variable. Is there a right way to do this?

Given a root Task variable of:

vars:
  PARAMETER_NAME: "/{{.SYSTEM_NAME}}/${TERRAFORM_VARIABLE}"

Below is an example of me having to introduce a new local bash variable.

  example:
    cmds:
      - |
        if [ -z "{{.TERRAFORM_VARIABLE}}" ]
        then
          PARAMETER_NAME="{{.OTHER_PARAMETER_NAME}}"
        else
          PARAMETER_NAME="{{.PARAMETER_NAME}}"
        fi
        echo "${PARAMETER_NAME}" 
        echo "{{.PARAMETER_NAME}}"

Thank you,

[ghostsquad]

Vars cannot be updated per se, they can only be overwritten. Unfortunately, the way vars currently work is that you don't actually get access to the value as it is declared in a higher scope, if you declare a var in a child scope with the same name.

The recommended approach is to declare a new var (different name) and then reference the global var.

Here's an example:

vars:
  PARAMETER_NAME: "/{{.SYSTEM_NAME}}/${TERRAFORM_VARIABLE}"

tasks:
   example:
      vars:
        DERIVED_PARAMETER: |
           {{if (eq .TERRAFORM_VARIABLE "")}}{{.OTHER_PARAMETER_NAME}}{{else}}{{.PARAMETER_NAME}}{{end}}
      cmds:
      - echo '{{.DERIVED_PARAMETER}}'

[prodigy-byron-jones]

Thank you for the answer @ghostsquad! Should the docs not be updated to specifically call this out? I know there is the order of precedence segment under variables but feel being even more explicit here could add additional value to the docs.

Do you think that allowing Task variable updates within the cmd block is something that may be a candidate for v4 or is it too deeply entrenched to alter?

Last, question: How would your derived parameter block look if I wanted a ternary (as it might be a cleaner use in this circumstance)?

[ghostsquad]

Oh I just realized that ternary existed last night.

{{eq .TERRAFORM_VARIABLE "" | ternary .OTHER_PARAMETER_NAME .PARAMETER_NAME}}

[ghostsquad]

Yes, I think it makes sense to talk about variable evaluation order in the docs. PRs Welcome! 🤗

[prodigy-byron-jones]

I will be honest, every single time I think I have it right in my mental model I prove myself wrong 😆.

For example initially I expected the flow to be in the reverse order as communicated by the doc (intuitively speaking) because typically I would want to set some default at the lowest level (the actual task or IN the task) and then allow it to be overridden at each higher level - with the command line allowing full override. However, with Task I am effectively scoping the var at a particular level and not able to surface it. I assume this is for security reasons?

Thank you for the ternary example - it is so wonderfully clean 😄