--status report failures on CI and is not debuggable

[ssbarnea]

Description

In order to prevent misconfiguration on task steps that are supposed to run only when needed we use the task foo && task foo --status pattern on CI.

Still we recently discovered that some tasks are very often failing on MacOS runners.

We tried to debug but we were never able to identify what makes task believe something changed.

Usual git status --porcelain --ignored should help identify if some files that are part of src patterns did change but in our case it keeps reporting nothing related to these patterns.

Sadly there is no known option that could be used to improve the debugging of this issue as we would clearly need to log the list of files taskfile identifies as source before the first run and before the second run in order to identify the reason.

Version

3.46.4

Operating system

macos

Experiments Enabled

Gentle Force

Example Taskfile

# simplified section to highlight the problem as the full file is quite big
version: "3"
tasks:
 ui:
    vars:
      TEST_PREFIX: "{{ coalesce .TEST_PREFIX .TASK }}"
    sources:
      - src/**/*.ts
      - test/*.ts
      - test/ui/**/*.{ts,js}
      - webviews/**/*.vue
      - exclude: test/testFixtures/.vscode/
      - exclude: test/testFixtures/common/collections/
    generates:
      - out/junit/ui/{{.TEST_PREFIX}}-test-results.xml
    cmds:
      - true
    interactive: true

[ssbarnea]

I will repeat: even if my main machine is MacOS, I was not able to reproduce this bug locally, it does only seem to be present on github runners. Example https://github.com/ansible/vscode-ansible/actions/runs/21288074566/job/61274147629?pr=2482

[trulede]

Try

cmds:
      - for: sources
        cmd: echo {{ .ITEM }}

which is documented: https://taskfile.dev/docs/guide#looping-over-your-task-s-sources-or-generated-files

You can also print the contents of the checksum file/folder, and use --verbose logging which might also be interesting.

[ssbarnea]

Thanks!!! I am going to do this on Monday and report back the outcomes as it will clearly be useful to others. Maybe even contribute a FAQ section for debugging state chages.

One more question: would you mind accepting a contribution for a new feature that would make the status check implicit for some specific tasks? ..maybe even one that would clearly state what changed and determined it to fail?

Example: adding "check-status: false" as default for compatibility reasons. Once you set it true, it will run status after running the task to ensure that the task behaves as designed.

Side question: i have one or two task that receive parameters/arguments, how can I ensure that their status is kept separated for each set of these?