Apply consistent timestamps to files added to a fat archive

[philwebb]

555132e reverted BootZipCopyAction to use GregorianCalendar, but I still think this value might change depending on the local timezone. We need to review how we should actually set the date.

[scottfrederick]

From issue #20927, which drove that change, I observed that files written to the archive by the Gradle plugin could have either the fixed timestamp of Feb 01 00:00:00 or the timestamp Jan 31 18:00:00 when using OffsetDateTime.

     0 Fri Feb 01 00:00:00 CST 1980 org/
     0 Fri Feb 01 00:00:00 CST 1980 org/springframework/
     0 Fri Feb 01 00:00:00 CST 1980 org/springframework/boot/
     0 Fri Feb 01 00:00:00 CST 1980 org/springframework/boot/loader/
  5303 Fri Feb 01 00:00:00 CST 1980 org/springframework/boot/loader/ClassPathIndexFile.class
 30287 Thu Jan 31 18:00:00 CST 1980 BOOT-INF/lib/spring-boot-jarmode-layertools-2.3.0.M4.jar
   996 Thu Jan 31 18:00:00 CST 1980 BOOT-INF/classpath.idx
  7339 Thu Jan 31 18:00:00 CST 1980 BOOT-INF/layers.idx

There is a six hour difference between the timestamps, and my local time is six hours offset from UTC.

When using GregorianCalendar the timestamps are consistent, but I can't yet explain the difference.

[scottfrederick]

On further review, the timestamps for the loader files are unrelated to the timestamps for the layertools jar and index files. It just happens that they end up with the same TZ-specific value when using GregorianCalendar to generate the fixed date.

Gradle archive tasks have a preserveFileTimesamps property. When the property is true (the default), tasks should not manipulate timestamps when copying files. In the test cases mentioned above, preserveFileTimestamps=true. The Feb 01 00:00:00 timestamp on the loader files is not being set by the plugin, but is reflecting the timestamp of each archive entry when read using new ZipInputStream(getClass().getResourceAsStream("/META-INF/loader/spring-boot-loader.jar")) and copied to the output archive unchanged.

When preserveFileTimestamps=false the plugin fixes the timestamp of all files in the archive to the same value, as expected.

I'll un-revert the timestamp change to use OffsetDateTime so that the fixed date, when applied, is tied to UTC instead of the building machine's default TZ.

[scottfrederick]

The Boot Maven plugin does not use its own constant for timestamps, but uses the value of project.build.outputTimestamp. We should consider whether we want this date to be TZ-independent also.

[wilkinsona]

For Maven where you have to specify the timestamp, I think we should use whatever the user has configured. The timestamp can include a zone (as the example, 2019-10-02T08:04:00Z, in the docs does). I think that should be sufficient.

[scottfrederick]

These are some questions for us to consider:

1. The Gradle plugin applies a fixed timestamp to classpath.idx and layers.idx when they are added to the archive. The Maven plugin does not apply a timestamp, so the index files get the current date/time. We should harmonize this behavior. Is the fixed timestamp the right approach for index files?

2. If a fixed timestamp is applied to index files, each plugin will need to have a constant for the timestamp. The Gradle plugin currently has such a constant, the Maven plugin does not. Should we use a time zone independent timestamp (e.g. using OffsetDateTime) to improve reproducibility across build machines, or a time zone specific timestamp (e.g. using GregorianCalendar) to match what Gradle uses when preserveFileTimestamps=true?

   The Boot build instructs Gradle to fix the timestamps of the loader and layer tools jars, using Gradle's time zone specific timestamp. The timestamps on these files are preserved when they are copied to the fat jar. If the Gradle plugin uses a different timestamp from Gradle's default, then the timestamps on the loader classes and layer tools jar might be different from the timestamps on index files (unless the building machine happens to be in UTC).

   Both plugins provide a means to fix the timestamps of all files in the archive. The Maven plugin requires the user to set the project.build.outputTimestamp property, so the date that gets applied is out of our control. The Gradle plugin requires the user to set preserveFileTimestamps=true, and the archive tasks use a hard-coded value. The built-in Gradle tasks will apply the time zone specific date, bootJar would override this value with our plugin's hard-coded date.

[scottfrederick]

After further discussion, we've decided to:

• Use a current timestamp for classpath.idx and layers.idx file when they are added to the archive, instead of applying a fixed timestamp as the Gradle plugin does currently.
• Use the same GregorianCalendar time zone specific fixed timestamp as Gradle when the Spring Boot Gradle plugin needs to apply a timestamp (i.e. when preserveFileTimestamps=true).
  • Add a test to verify that the Spring Boot Gradle plugin's fixed timestamp matches the Gradle timestamp (which is in an internal Gradle class).
• Apply a timestamp to the exploded loader directories and classes, and to the bundled layer-tools jar, that matches the build timestamp of either the plugin or the loader-tools jar.

[philwebb]

I've raised an issue with the Gradle team to see if they want to switch as well.