More accurately document the effects of the buildInfo task never being up-to-date by default

[jnizet]

The documentation of the gradle plugin says:

The default value for build.time is the instant at which the project is being built. A side-effect of this is that the task will never be up-to-date and, therefore, builds will take slightly longer as more tasks will have to be executed.

This is correct, except for the "slightly longer" part. Since it affects the resources of the project, and since the resources are an input of the test task, using buildInfo() forces all the tests to be executed at each build, which makes it quite more than "slightly" longer :-)

Of course, as documented, we can set the time to null, but then we lose valuable information.

I managed to improve things by using the following trick: declare a task of type BuildInfo, make it a dependency of the bootJar task, and include its produced properties file into the jar file:

task buildInfo(type: org.springframework.boot.gradle.tasks.buildinfo.BuildInfo) {
    destinationDir = file("$buildDir/buildInfo")
}

bootJar {
    dependsOn buildInfo

    into('BOOT-INF/classes/META-INF') {
        from buildInfo.destinationDir
    }
}

This makes the build much faster, since it only has to recreate the jar file, instead of having to re-run all the tests and recreate the jar file.

Couldn't this be the default behavior of the buildInfo() call inside the springBoot closure? You would lose the ability to load the build-info properties file inside tests, but my guess is that no one does that. There might of course be other side-effects that I could miss (on bootRun, maybe).

[wilkinsona]

using buildInfo() forces all the tests to be executed at each build, which makes it quite more than "slightly" longer :-)

Good point. I'm pretty sure that this hadn't occurred to me when I wrote "slightly".

Couldn't this be the default behavior of the buildInfo() call inside the springBoot closure? You would lose the ability to load the build-info properties file inside tests, but my guess is that no one does that. There might of course be other side-effects that I could miss (on bootRun, maybe).

Reworking the default bootInfo this way doesn't feel quite right to me. We've had problems in the past when trying to do things in an atypical way with Gradle, and I think this would be another example of that. As you've already suggested, it would adversely affect bootRun as the buildInfo.properties would no longer be available to it.

I'll keep this issue open as I'd like to see if there's another way that we can solve the problem without fighting against the Gradle way of doing things.

[wilkinsona]

Unfortunately, I can't see a better way to do this that isn't overly complicated. I wondered about filtering the test task's classpath, but that filtering is only possible at the level of a classpath root, rather than an individual file beneath that root.

Even if some filtering of the classpath was possible so that the task would be identified as up-to-date, I'm not sure that we want to get into a situation where tests are being run against a subtly different classpath to that which will be used at runtime.

In the absence of an alternative, I think we should use this issue to rework the documentation. In particular, it should make it clear that the tests will be run each time.