#1114 print build path in projectHealth #1178
Conversation
|
I've updated the implementation moving the gradle file name prepending to |
There was a problem hiding this comment.
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.
| @@ -15,6 +15,8 @@ import org.gradle.api.tasks.TaskAction | |||
|
|
|||
| abstract class ProjectHealthTask : DefaultTask() { | |||
|
|
|||
| private val buildFilePath = project.buildFile.path | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| private fun prependBuildPath(consoleReport: String): String { | ||
| return buildFilePath + "\n" + consoleReport | ||
| } |
There was a problem hiding this comment.
I would prefer this be inlined.
val output ="${project.buildFile.path}\n$consoleReportfor example.
| def "projectHealth prints build file path (#gradleVersion)"() { | ||
| given: | ||
| def project = new AbiGenericsProject(SourceKind.METHOD) | ||
| gradleProject = project.gradleProject | ||
|
|
||
| when: | ||
| var result = build(gradleVersion, gradleProject.rootDir, 'projectHealth') | ||
|
|
||
| then: | ||
| assertThat(result.output).contains( | ||
| """${gradleProject.rootDir.getPath()}/proj/build.gradle | ||
| |Existing dependencies which should be modified to be as indicated: | ||
| | api project(':genericsBar') (was implementation) | ||
| | api project(':genericsFoo') (was implementation) | ||
| |""".stripMargin()) | ||
|
|
||
| where: | ||
| gradleVersion << gradleVersions() | ||
| } |
There was a problem hiding this comment.
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.
| gradleProject = project.gradleProject | ||
|
|
||
| when: | ||
| var result = build(gradleVersion, gradleProject.rootDir, 'projectHealth') |
There was a problem hiding this comment.
Please use def instead of var for consistency.
What would you prefer - address both |
Solves #1114 (only
projectHealth, but notbuildHealth).Prints absolute path of according
build.gradleof 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:
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.