Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit environment variable is not honoured when calling another task #593

Open
chris-garrett opened this issue Oct 28, 2021 · 7 comments

Comments

@chris-garrett
Copy link
Contributor

  • Task version: 3.3.0
  • Operating System: Windows 10 (git bash)

Taskfile

version: '3'

vars:
  VAR_GLOBAL: IM_VAR_GLOBAL

env:
  ENV_GLOBAL: IM_ENV_GLOBAL

tasks:

  env_caller:
    cmds: 
      - { task: env_subtask, env: { ENV_CALLER_ARG: IM_ENV_CALLER_ARG }, vars: { VAR_CALLER_ARG: IM_VAR_CALLER_ARG }}
    env: { ENV_CALLER: IM_ENV_CALLER }
    vars: { VAR_CALLER: IM_VAR_CALLER }

  env_subtask:
    cmds:
      - echo ENV_GLOBAL=$ENV_GLOBAL
      - echo ENV_CALLER=$ENV_CALLER 
      - echo ENV_CALLER_ARG=$ENV_CALLER_ARG 
      - echo VAR_GLOBAL={{.VAR_GLOBAL}}
      - echo VAR_CALLER={{.VAR_CALLER}}
      - echo VAR_CALLER_ARG={{.VAR_CALLER_ARG}}

Output

$ ./task env_caller
ENV_GLOBAL=IM_ENV_GLOBAL
ENV_CALLER=
ENV_CALLER_ARG=
VAR_GLOBAL=IM_VAR_GLOBAL
VAR_CALLER=
VAR_CALLER_ARG=IM_VAR_CALLER_ARG

I expect that ENV_CALLER_ARG should be valid in env_subtask. Am I missing something?

@chris-garrett chris-garrett added the type: bug Something not working as intended. label Oct 28, 2021
@aminya
Copy link
Contributor

aminya commented Nov 14, 2021

I hit a similar situation. Although I specify CC and CXX, it still uses the global environment variable.

# https://taskfile.dev
version: "3"

tasks:
  init_debug_mingw:
    env:
      CC: gcc
      CXX: g++
    cmds:
      - echo {{.CC}}

clang is printed instead of GCC

This is also related to #185

@kerma
Copy link
Contributor

kerma commented Dec 4, 2021

There are couple of different issues here. @chris-garrett your env_caller env and vars values are only applicable for shell commands called within that command block. If you call another task with -task: env_subtask you can only pass vars to it. env block is ignored.

cmds:
- task:env_subtask
  vars: 
     VAR_CALLER_ARG: IM_VAR_CALLER_ARG

@aminya you're mixing up vars and env syntax. Both commands work here:

# https://taskfile.dev
version: "3"

tasks:
  one:
    vars:
      CC: gcc
    cmds:
      - echo {{.CC}}

  two:
    env:
      CC: gcc
    cmds:
      - echo $CC

@kerma kerma removed the type: bug Something not working as intended. label Dec 4, 2021
@chris-garrett
Copy link
Contributor Author

@kerma welcome to the collabs list!

There are couple of different issues here. @chris-garrett your env_caller env and vars values are only applicable for shell commands called within that command block. If you call another task with -task: env_subtask you can only pass vars to it. env block is ignored.

Can you explain why this is? Is this actually the behaviour that is desired?

Without this we are forced to convert ENVs to VARs and carry them around until you convert back to ENV when you need it. It's very clumsy on large projects.

@kerma
Copy link
Contributor

kerma commented Dec 6, 2021

@chris-garrett I'm new to the project, so cannot tell the historical reasons, but atm it's how it's implemented.

There is another issue slightly related to this: #585.

To me it feels like task is missing a well documented context which is creating the confusion. To be honest I think it may be something I'd look into. Having a simple context and inheritance rules for dir, env and vars would probably make life easier for everyone. However it would be a major change and would need a new taskfile version.

@dustinlharrison
Copy link

dustinlharrison commented Jul 19, 2023

@kerma and @chris-garrett I "discovered" the same behaviour as well, and the behaviour is documented:

After much pain, testing and searching, I did finally realize that a shell command was being handled different than a task command from the task API reference:

env map[string]Variable A set of environment variables that will be made available to shell commands.

This was surprising since the schema suggests that it applies to all uses of env within the current task declaration. Whether this is intended, a bug or a feature request, I think there is a very strong case for it to work, and if not, then
env should be removed from the target declaration and only be supported by individual cmd declarations.

I think making it work for both task invocation and shell invocation encourages reusability of tasks and 12 factor apps.

version: 3

tasks:
  start:
    vars:  # Passing in config by using vars is recommended
      NAME: '{{ .NAME | default "my-service" }}'
    env:
      PGDATABASE: '{{.NAME}}-db'
    cmds:
      - echo "Works here as promised: $PGDATABASE"
      - task: start-db # PGDATABASE is not passed in even though it is at the task level.
  start-db:
    cmds:
     - psql # Invoked by `start` or directly from command line with env configured (12 factor)

@andreynering I think this issue was opened before the labelling system was developed, can you consider applying the appropriate labels since I don't have permission?

@treybrisbane
Copy link

This bit me as well, today. 😢

Is it difficult to fix?

If it's not practical/desirable to have the env vars implicitly apply to sub-task calls, could/should we instead perhaps give sub-task calls a dedicated env block to allow passing env vars explicitly?
E.g.

version: 3

tasks:
  caller:
    cmds:
      - task: callee
        env:
          FOO: bar

  callee:
    cmds:
      - echo "${FOO}"

This would fit nicely with sub-task calls' existing var block, and at least give us some way of passing env vars to sub-tasks.

@trim21
Copy link
Contributor

trim21 commented Jul 12, 2024

yes, I think we should add a env option to task call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants