How to detect misconfigured dependencies that trigger unnecessary task reruns?

[ssbarnea]

On project with multiple developers we are unlikely to be able to have a single person gating changes made to taskfiles and even if we would do, it is too easy to introduce dependency errors which would make task run when they should not.

To address this one could try to modify how tasks are run on CI to cause failures if on second consecutive run they do not report up-to-date.

The issue is that the boilerplate code needed for doing this is really ugly

task build && task build --status

Is there a better/easier way to implement this?

Ideally we should be able to declare which tasks are supposed to behave like this and task would do the checking at the end by itself. Such feature would make much easier to maintain task files.

[wellkilo]

There is no current declaration that means “run this task and then assert that a second run would be up to date.” The existing --status mode is exactly the side-effect-free assertion: it returns non-zero if any supplied task is not up to date. So your two-command check is the correct primitive.

You can remove repetition by defining one internal CI wrapper per public task (or generate these wrappers if you have many):

version: '3'

tasks:
  build:
    sources: ['src/**']
    generates: ['dist/**']
    cmds:
      - ./build.sh

  ci:build-idempotent:
    internal: true
    cmds:
      - task: build
      - '{{.TASK_EXE}} --status build'

Then CI runs only:

task ci:build-idempotent

The second command does not execute build; Executor.Status only compiles the task and asks the fingerprinter whether it is up to date. The CLI contract is documented as “check without running” and returns non-zero when any task is stale.

One important limit: this verifies the sources / generates / status contract you declared. It cannot detect outputs that the Taskfile forgot to list. For high-value build tasks, also compare a manifest/hash of the intended output tree or run the build in a clean checkout.

So there is not a hidden shorter flag that combines both phases today; wrapping task build followed by {{.TASK_EXE}} --status build is the reusable approach. If that addresses the CI pattern, please mark this as accepted.