#1114 print build path in projectHealth

[seregamorph]

Solves #1114 (only projectHealth, but not buildHealth).
Prints absolute path of according build.gradle of the project module. This can be pretty helpful in large multi-module projects, especially when there is no full matching between module name and submodule directory.

Sample task output:

> Task :utilities:projectHealth
/Users/morph/Projects/demo-gradle-multi-module/utilities/build.gradle
Unused dependencies which should be removed:
  testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.2'

Using absolute path

The absolute path is printed intentionally as it seems to be the best trade-off.
This path is recognized in IDEA to open file in "Navigate to File...":

For instance, if relative path is used, there can be ambiguity:

Also, the relative path is not always in parent directory (for included builds) and printing "../../parent/build.gradle" will not help navigating to the file in the IDE.

[seregamorph]

I've updated the implementation moving the gradle file name prepending to ProjectHealthTask not to cache the GenerateProjectHealthReportTask output with absolute path (while it's not a task input).

[autonomousapps]

Thanks for this contribution! I only worry about it being inconsistent with how buildHealth works, while simultaneously being concerned about how verbose it would be if buildHealth also had this behavior. But I'm happy to support this use-case, for the reasons you indicated.

[autonomousapps]

I don't think this should be an instance property. You can just move this down into the task action.

Oh, and of course I think that means that either buildFile or buildFile.path must then be a task input property.

[seregamorph]

The project (getProject()) cannot be executed inside of @TaskAction for tasks that are not explicitly marked as non-cacheable:

1 problem was found storing the configuration cache.
- Task `:proj:projectHealth` of type `com.autonomousapps.tasks.ProjectHealthTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/7.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

So this simple trick is used to resolve the project parameter on the phase before TaskAction execution and not to pass as Input from the plugin. You suggested to make it an input - Done. Initially I didn't mark it as input, because this task is not cacheable.

[autonomousapps]

I would prefer this be inlined.

val output ="${project.buildFile.path}\n$consoleReport

for example.

[seregamorph]

Done

[autonomousapps]

Could you instead create a new spec, ProjectHealthSpec, and put this test there? You can continue to use AbiGenericsProject, if you prefer. I realize that we don't have any specs that run projectHealth, so it makes sense to have that encapsulated somewhere.

[seregamorph]

Done

[autonomousapps]

Please use def instead of var for consistency.

[seregamorph]

Done

[seregamorph]

I only worry about it being inconsistent with how buildHealth works

What would you prefer - address both projectHealth and buildHealth in scope of a single PR or implement them separately?
The problem here is that these two tasks have different ways to aggregate and format reports.