-
-
Notifications
You must be signed in to change notification settings - Fork 615
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
Comments
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 |
There are couple of different issues here. @chris-garrett your env_caller 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 welcome to the collabs list!
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. |
@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. |
@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
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 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? |
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 version: 3
tasks:
caller:
cmds:
- task: callee
env:
FOO: bar
callee:
cmds:
- echo "${FOO}" This would fit nicely with sub-task calls' existing |
yes, I think we should add a |
3.3.0
Windows 10 (git bash)
Taskfile
Output
I expect that ENV_CALLER_ARG should be valid in env_subtask. Am I missing something?
The text was updated successfully, but these errors were encountered: