bootBuildInfo does not re-generate build-info.properties (2.0.0.RC2)

[gillius]

We are using Spring Boot 2 in a few projects, and I have noticed that build-info.properties has never changed since the first build of the project and that /actuator/info returns this first build information.

It appears on each run, the bootBuildInfo always shows UP-TO-DATE and doesn't re-run.

I can reproduce this with simple starter project:

1. Used start.spring.io to generate sample project. Spring Boot 2.0.0.RC2, gradle-4.5.1-all.zip, Java 8
2. Add springBoot { buildInfo() } to build.gradle. I placed this after "sourceCompatibility" line.
3. Run gradlew bootBuildInfo, observe build/resources/main/META-INF/build-info.properties is version 0.0.1-SNAPSHOT
4. Update build.gradle version='1.0.0-SNAPSHOT'
5. Run gradlew bootBuildInfo, it will say task is "UP-TO-DATE". Observe build-info.properties has NOT changed in build.version or build.time values.

Specific to my use case: as I am behind firewall I modified build.gradle repositories and wrapper properties to point to Maven (Nexus) repo mirror and gradle-4.5.1-all.zip on my network. These are mirror of public files so I don't expect this step to matter.

Our project uses 2.0.0.RC1 but the example project above exhibited same behavior with RC1 or RC2.

Workarounds: delete build-info.properties, such as via clean task

[gillius]

Here is an automated workaround I am going to use:

def removeBootBuildInfoWorkaround12266 = task(type: Delete, 'removeBootBuildInfoWorkaround12266') {
	delete new File(buildDir, 'resources/main/META-INF/build-info.properties')
}

tasks.find { it.name == 'bootBuildInfo' }.dependsOn(removeBootBuildInfoWorkaround12266)

This causes bootBuildInfo to generate new file each time. It is a little disappointing that it means running gradle each time causes re-generation of boot jar, but there's no way around that if we want a truly updated build stamp.

Some might prefer to add clean before doing a "release" build that matters so in normal development gradlew only does something when something changes (one of the best parts of gradle)

[wilkinsona]

The problem is that build.time isn't part of the task's BuildProperties. The BuildProperties are the task's input and, as it doesn't contain the time, the task is incorrectly considered to be up-to-date. The easy fix would be to configure the BuildInfo task so that it's never up-to-date. The better fix is to expose the time as a property. This will allow it to be considered in the up-to-date checks and, if we add a setter too, will also allow the time to be set to a fixed value (including null) and fix #12111 at the same time.

[wilkinsona]

There's a bit more to this as I neglected to consider the fact that changing the project's version still left the task up-to-date. That alone should have been enough to trigger a new build.

[gillius]

Yes, the build time I could actually do without, especially if it can be configured to not have the time... Then it can really be "up-to-date". It's the version number that is the most important because I have a production service that is 1.1.0 version but it reports version 1.0.0 from the info endpoint.

In the end I also decided when running production builds to always run gradle clean first. I always did that from Maven but I suppose I trusted Gradle's build cache / up-to-date checking but that appears to be naive for a production build.

Thanks for the quick response.

[gillius]

I notice in the commit the updated documentation says that it's possible to set time to null. I may actually do that to allow up-to-date checks to work as it's the version I care the most about.

I notice you copy the fields from project to fields when getter is called, but only once. Are those fields in Gradle project considered immutable or can they change later in the build?

[wilkinsona]

I notice you copy the fields from project to fields when getter is called, but only once. Are those fields in Gradle project considered immutable or can they change later in the build?

They're not immutable, but they shouldn't change once the task is being executed which is when the getters are called.