Can I execute compareGradleBuilds on a subproject of a multimodule project?

(Jörn Huxhorn) #1

I tried it like this but it didn’t work:

project.allprojects { project ->
 apply plugin: 'compare-gradle-builds'
    compareGradleBuilds {
  sourceBuild {
   gradleVersion "1.3"
   projectDir project.projectDir
  targetBuild {
   gradleVersion "1.4-rc-1"
   projectDir project.projectDir

The rationale for this is that I’d like to recheck subprojects that failed during a previous compareGradleBuilds execution.

(Luke Daley) #2

It wasn’t designed to support subprojects, it kind of treats the thing as an opaque whole.

Is the issue that building the things to be compared takes too long?

(Jörn Huxhorn) #3

Yes, mostly.

In my case the differences seem to be solely caused by SNAPSHOT dependencies that got updated by the CI server while the build was still in progress.

Executing that task took about 45mins so I’m not too keen on retrying the whole thing only to realize that the same thing happened again.

Beside that, I think it generally makes sense to offer that functionality for subprojects.

(Luke Daley) #4

what exactly went wrong with your efforts before? you might have more luck changing the tasks that are run instead of running a subproject individually.

(Jörn Huxhorn) #5

war files differed because contained SNAPSHOT dependencies differed.

Also, groovy modules seem to produce class files with “entries are of identical size but have different content” for (as of yet) unknown reasons. Which is quite strange.

(Luke Daley) #6

Groovy puts compile time timestamps into the class files. This is what you’re seeing.

Our plan for this is to allow transforming files before comparison, so we’d remove the timestamp using something like ASM.

(Jörn Huxhorn) #7

Ah, ok. So this is more or less a non-issue concerning build safety/compatibility.

The other thing that produces different output every time is javadoc.

The reason for this is

But I guess you know that already. Just consider this as feedback concerning the compare task.

(I still think that comparing separate submodules would make sense. At least in some cases.)

(Luke Daley) #8

Yeah, that’s another one to deal with.

You still haven’t explained exactly how using subprojects didn’t work.

(Jörn Huxhorn) #9

I thought you meant what went wrong during the original compare.

With the above “projectDir project.projectDir” configuration the ‘compareGradleBuilds’ task would still execute a complete build regardless of the subproject I started the task in. ‘:subproject1:compareGradleBuilds’ didn’t work either.

It just tried to do another full compare but I quit it.

Meaning: It did work as expected if the expected behavior is to always perform a full compare. But I expected it to behave differently so it “didn’t work” as I expected.