-
New Feature
-
Resolution: Fixed
-
Major
Currently ModuleDetector[1] is capable of detecting module names from pom.xml files, build.xml files, and MANIFEST.MF files. But I would also like to look for Gradle module names.
Typically in a multi-module Gradle project, the module name would match the subdirectory that the module is in, but it can also be overridden by settings.gradle[2]. The easy way would be to find the build.gradle file the same way it looks for the other files, and take that file's parent directory name:
./
|-- settings.gradle
|-- build.gradle
|-- moduleA/
|-- build.gradle
|-- build/ (contains for example **/checkstyle-result.xml)
|-- moduleB/
|-- build.gradle
|-- build/
So as an example, when we find ./moduleA/build/reports/checkstyle/checkstyle-result.xml, that belongs to the ":moduleA" gradle module.
[1] https://github.com/jenkinsci/analysis-model/blob/master/src/main/java/edu/hm/hafner/analysis/ModuleDetector.java
[2] https://docs.gradle.org/current/userguide/organizing_gradle_projects.html
[JENKINS-62087] Detect Gradle module names
I was planning to put together a PR last night and then I had to stop.
One question is: would it be worth it to read the full Gradle model to figure out the resolved and configured module names, or should we just start with a way to detect the common base directory name between the report file and the nearest build.gradle file? The base directory would work for the most common scenario, but it's possible to redefine the module name or the $buildDir in which case it might not even be moduleA/build/.
I'll take a first pass at the simple case, and see if it proves useful.
I think it makes sense to start with the simple case. I think for the other approaches we also tried to be as simple as possible. We can refine that later on if someone encounters problems.
Makes sense - I've pushed the simple case(s) with just looking for parent directory names of build.gradle, to my fork (haven't opened a PR yet), and also working on a way to parse the rootProject name from settings.gradle.
The rootProject case might be worth resolving, because most Jenkins projects will checkout their SCM into the workspace directory which matches the Jenkins job name (usually). So this might treat anything in the root project as if moduleName=jenkins-job-name.
You can check out current progress here: https://github.com/jhansche/analysis-model/commits/pr-62087
Pull request has been opened: https://github.com/jenkinsci/analysis-model/pull/362
Yes, that would be a nice improvement! Interested in providing a PR?