Add --include-deps flag to --status for recursive dependency checking

[solvingj]

Relates to: #669

Summary

This PR adds a new --include-deps flag that extends the --status functionality to recursively check task dependencies. When enabled, it will return exit code 1 if any task in the dependency tree is not up-to-date.

Motivation

Currently, task --status my-task only checks if my-task itself is up-to-date, ignoring whether its dependencies are up-to-date. This makes it difficult to determine if a task and all its dependencies are ready to run without actually executing them.

Changes

• Add new --include-deps flag that works with --status
• Recursively check all task dependencies when flag is enabled
• Return exit code 1 if any dependency is not up-to-date
• Extract checkTaskStatus helper for reusable status checking
• Leverage existing traverse function for dependency traversal
• Add deduplication to avoid checking shared dependencies multiple times
• Add comprehensive test suite with 7 test scenarios
• Add testdata with tasks having various dependency configurations
• Flag validation ensures --include-deps requires --status

Usage

# Check if a task and all its dependencies are up-to-date
task --status --include-deps my-task

# Without --include-deps, only checks the task itself (current behavior)
task --status my-task

Example

Given this Taskfile:

version: '3'

tasks:
  build:
    deps: [lint, test]
    cmds:
      - go build
    sources:
      - "*.go"
    generates:
      - app

  lint:
    cmds:
      - golangci-lint run
    sources:
      - "*.go"

  test:
    cmds:
      - go test ./...
    sources:
      - "*.go"
      - "*_test.go"

# Check if build task is up-to-date (ignores lint and test dependencies)
$ task --status build
# Exit code 0 if build's sources/generates are up-to-date

# Check if build AND its dependencies (lint, test) are all up-to-date
$ task --status --include-deps build
# Exit code 0 only if build, lint, AND test are all up-to-date

Implementation Details

• Reuses existing traverse() function from watch.go for dependency walking
• Tracks visited tasks in a map to avoid duplicate checks when tasks share dependencies
• Uses the same fingerprint.IsTaskUpToDate() logic that checks both status: commands and sources:/generates: fields
• Reports which specific task(s) failed the up-to-date check

Testing

• Added TestStatusWithDeps() with 7 comprehensive test scenarios
• Tests cover single-level and multi-level dependencies
• Tests verify behavior with and without the flag
• All existing tests continue to pass

[timrulebosch]

@solvingj In my mind, --status should return 0 if, when I call the task, no tasks would run. That is the point (I think).

So with this PR, you are suggesting that --status would return 0 but if I called the task then actually the task would run. If that is the case, I think you can make the behaviour of --include-deps as the normal operation (and you fixed/improved things!). Then dispense with the complexity of an additional flag. Perhaps, some verbose logging to understand which dep/status is evaluated, and the return value, to assist in debug.

If you wanted to know the status of a dependency (i.e. build) then simply: task --status build.

[solvingj]

I think you can make the behaviour of --include-deps as the normal operation

@timrulebosch this would be a breaking behavior and render this PR unacceptable.

There are lots of other ways to approach the option, but I partially expect this PR to be declined in favor of an alternative approach as mentioned in that discussion, whereby tasks can add an additional flag to their dependency declarations, indicating that "if this deps runs, i need to run". For cases where deps don't generate any file which can be added to "source" of dependents.