Skip to content

.task directory generation should respect dir attribute #2561

@Muzosh

Description

@Muzosh

Description

Problem

Including a taskfile which contains any task with generates: breaks the checksum check depending on from which taskfile the task was run.

Example

Consider following structure:

.
./docs
./docs/some-source-files/*.md
./docs/Taskfile.docs.yml
./Taskfile.main.yml

The Taskfile.docs.yml:

version: '3'

tasks:
  pdf:
    desc: "Compile source files to PDF"
    sources:
      - "./some-source-files/*.md"
    generates:
      - "Docs.pdf"
    cmds:
      -  <some command that generates Docs.pdf from source markdown files>
    silent: false

I want to make pdf task available from the root directory. Taskfile.main.yml:

version: '3'

includes:
  docs_generation:
    taskfile: "./docs/Taskfile.docs.yml"
    dir: "./docs"
    aliases: [dg]

tasks:
  some_other_tasks:

Problem reproduction

cd ./docs && task pdf produces a .task directory with a checksum name pdf in ./docs/.task/checksum/pdf

However, task dg:pdf generates .task directory in root directory, with different name: ./.task/checksum/docs_generation-pdf

Expectations

If I include a pdf task from docs generation in main taskfile, I explicitly set dir: "./docs" so that Task should be run from within that directory. I would expect the .task directory to be also created/checked from within that directory.

This also means that the docs generation will be run even if it's up-to-date, because some other user run it from different taskfile than me. (Yes, I want to commit the checksums because I also commit the generated PDF).

Tried solutions

Setting TASK_TEMP_DIR=./docs/.task task dg:pdf + adding label: pdf to the pdf task solves this. However, what if I want to have multiple inclusions, not only from docs folder, where the included task has generates:?

I would have to type separately TASK_TEMP_DIR=./where-target-taskfile-is-located/.task everytime based on which included task I'm about to run. I believe this is not intented.

Metadata

Metadata

Assignees

No one assigned

    Labels

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

    Type

    No type
    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