Skip to content

Propagate Parent Task Environment Variables to Subtasks #1854

Closed as not planned

Description

@borjapazr

Hello! 👋

Description

I would like to request a feature that allows environment variables defined at the parent task level to be propagated and accessible in subtasks invoked via the task: subtask command.

Currently, when a parent task defines environment variables via the env block, these variables are not available in subtasks unless redefined at the subtask level. The expected behavior is for the parent task's environment variables to be accessible and expanded within any subtasks it calls, allowing for a more modular and DRY approach to managing environment variables across tasks.

Example Use Case

Consider the following Taskfile.yml:

version: "3"

tasks:
  default:
    cmds:
      - task: print
    env:
      WORLD: hello world!

  print:
    cmds:
      - echo $HELLO $WORLD
    env:
      HELLO: hello

Expected Behavior

  • When running task, the output should be: hello hello world!
  • The WORLD variable defined in the default task should be accessible within the print task without needing to be redefined in the print task.

Actual Behavior

  • Currently, the WORLD variable is not propagated to the print task. The echo $HELLO $WORLD command only has access to the HELLO variable defined in the print task, resulting in incomplete variable expansion.

Motivation

This feature would improve task reusability and prevent duplication of environment variables across tasks. For example, in a real-world scenario, services might share common environment variables such as database connection details, API keys, or service endpoints, which are defined once in a parent task but need to be accessible across multiple subtasks.

Having to redefine these variables at each subtask level leads to repetition and increases the risk of inconsistencies and errors. Allowing environment variables to be passed down from parent to subtask would align Taskfile behavior with what is expected in many other task runners and scripting tools, where a parent task's environment variables are inherited by default by its children.

Suggested Implementation

When a task invokes another task using the task: subtask syntax, the environment variables defined in the parent task should be automatically included in the environment of the subtask, unless explicitly overridden by the subtask’s own env block.

If there are conflicting variable names between the parent and child tasks, the child task's env block should take precedence, maintaining current behavior for explicit overrides.

Conclusion

This feature would enhance the flexibility and usability of Taskfile by allowing environment variables to flow between parent and child tasks. This would make it easier to structure tasks in a DRY and maintainable manner, particularly in large-scale projects with complex environment requirements.

I appreciate your consideration of this feature request. Please let me know if any further details or clarifications are needed.

Thanks in advance. 🙏

Best regards!

Activity

  1. siku4 commented on Oct 14, 2024

    @siku4

    Something similar is already discussed here #593 (comment)

  2. trulede commented on Jun 8, 2025

    @trulede
    Contributor

    @borjapazr hi, you need to use vars for this. Take this approach, use vars internally to the Tasfile, and env when you call
    a cmd.

    version: "3"
    
    tasks:
      default:
        cmds:
          - task: print
            vars:
              WORLD: hello world!
    
      print:
        env:
          HELLO: hello
          WORLD: {{.WORLD}} 
        cmds:
          - echo $HELLO $WORLD
    
  3. added
    state: working as intendedThe issue described is working as originally intended.
    and removed
    state: needs triageWaiting to be triaged by a maintainer.
    on Dec 9, 2025
  4. trulede commented on Dec 9, 2025

    @trulede
    Contributor

    Hi, you can do this with the aforementioned method, or with the following techniques:

    • use .envfiles
    • use yaml anchors
    • use var .ref

    Each method works really well. You just choose the one that makes the most sense for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    state: working as intendedThe issue described is working as originally intended.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions