Clearly error when ownership check fails when walking parent directories to find a Taskfile

[deviantintegral]

I ran into a tricky issue where Task wasn't finding an expected Taskfile: https://github.com/orgs/ddev/discussions/6273

What was confusing to me is that https://taskfile.dev/next/usage/#running-a-taskfile-from-a-subdirectory says

it will walk up the file tree until it finds one (similar to how git works)

I think it's common for this to refer to git not crossing mounted file systems when looking for a .git directory. It wasn't clear to me that this would also involve ownership checks, which is done here: https://github.com/go-task/task/blob/40d77156df28e87c7cded7d99f312d98257439fc/taskfile/taskfile.go#L148-L150

I assume this is all to prevent potential security issues like the one in Git https://github.blog/2022-04-12-git-security-vulnerability-announced/.

It'd be great if Task could either:

• Clearly say why it stopped walking parent directories.
• Or, if we don't need to check ownership then don't.

[NikitaCOEUR]

Same problem on my side, an issue in a GITHUB ACTION CI running in a container.

I am working in a child directory of the GitHub repository, and the owner is different between :

• the root directory of the repo (owned by the UID of the user running the container [1001 for the runners hosted by GitHub])
• and child directories (owned by user root : https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) because it is root who executes the actions of the GitHub Action checkout within the container.

Also, if no Taskfile is found by going up from the child directories to the root of the repository, no Taskfile is found at the root either since the owner has changed...

Only workaround: execute the task by targeting the Taskfile directly:

task --taskfile "${GITHUB_WORKSPACE}/Taskfile.yml" ...