Vars can be included in other vars, but env vars not in other env vars

[lostkamp]

• Task version: Task version: v3.36.0 (h1:XVJ5hQ5hdzTAulHpAGzbUMUuYr9MUOEQFOFazI3hUsY=)
• Operating system: Linux/Kubuntu
• Experiments enabled: no

Vars can be included in other vars

version: '3'

vars:
  SECRET_NAME: MySecret
  AZURE_APPLICATION_CLIENT_ID:
    sh: aws secretsmanager get-secret-value --secret-id {{.SECRET_NAME}} --query SecretString --output text | jq -r .client_id

tasks:
  test:
    cmds:
      - echo {{.AZURE_APPLICATION_CLIENT_ID}}

$ task -v test
task: [/home/lutz/Schreibtisch/test] Not found - Using alternative (Taskfile.yml)
task: dynamic variable: "aws secretsmanager get-secret-value --secret-id MySecret --query SecretString --output text | jq -r .client_id" result: "e01eb3c2-fb2f-47f7-a574-8a8db607796e"
task: "test" started
task: [test] echo e01eb3c2-fb2f-47f7-a574-8a8db607796e
e01eb3c2-fb2f-47f7-a574-8a8db607796e
task: "test" finished

Env vars can not be included in other env vars

version: '3'

env:
  SECRET_NAME: MySecret
  AZURE_APPLICATION_CLIENT_ID:
    sh: aws secretsmanager get-secret-value --secret-id $SECRET_NAME --query SecretString --output text | jq -r .client_id

tasks:
  test:
    cmds:
      - echo $AZURE_APPLICATION_CLIENT_ID

$ task -v test
task: [/home/lutz/Schreibtisch/test] Not found - Using alternative (Taskfile.yml)

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

aws: error: argument --secret-id: expected one argument

task: dynamic variable: "aws secretsmanager get-secret-value --secret-id $SECRET_NAME --query SecretString --output text | jq -r .client_id" result: ""
task: "test" started
task: [test] echo $AZURE_APPLICATION_CLIENT_ID

task: "test" finished

Vars can kind of be included in env vars

version: '3'

vars:
  SECRET_NAME: MySecret

env:
  AZURE_APPLICATION_CLIENT_ID:
    sh: aws secretsmanager get-secret-value --secret-id {{.SECRET_NAME}} --query SecretString --output text | jq -r .client_id

tasks:
  test:
    cmds:
      - echo $AZURE_APPLICATION_CLIENT_ID

This does not work on the first try, but is executed twice and works on the second try:

$ task -v test
task: [/home/lutz/Schreibtisch/test] Not found - Using alternative (Taskfile.yml)

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

aws: error: argument --secret-id: expected one argument

task: dynamic variable: "aws secretsmanager get-secret-value --secret-id  --query SecretString --output text | jq -r .client_id" result: ""
task: dynamic variable: "aws secretsmanager get-secret-value --secret-id MySecret --query SecretString --output text | jq -r .client_id" result: "e01eb3c2-fb2f-47f7-a574-8a8db607796e"
task: "test" started
task: [test] echo $AZURE_APPLICATION_CLIENT_ID
e01eb3c2-fb2f-47f7-a574-8a8db607796e
task: "test" finished

I guess that this behavior is intended? If so, it would be great to document this on the "Usage" web page (and maybe discourage people from doing the third thing).

I could provie a PR if you'd like.

[trulede]

Looking through the code ... my take:

Case 1; Works. Vars are processed in order, so later vars can reference earlier vars (resolved from a cache). This is I think, normal.

Case 2; When a task is compiled dynamic variables (i.e sh commands) are resolved based on the calling environment and emitted to the compiled task (which is then run). It might be possible to change that behaviour by adding an ongoing cache of the compiled env to the Compile object, and then use that cache here execext.RunCommandOptions.

Case 3; Here the situation is a bit easier. Env's are compiled before vars ... so what you try to do cannot work (on the first pass). On the second run, the var is (likely) found in a cache, and so that second attempt appears to work.

My take on the documentation is that it explains what works, which is sufficient. Assumed functionality should be avoided.

Case 2 is interesting. But is there are reason to do that? It could be better to set SECRET_NAME in the calling environment, or when calling task.