Don't emit timestamps when packaging to jar #5233
Conversation
| @@ -1400,7 +1400,7 @@ object Defaults extends BuildCommon { | |||
| Def.task { | |||
| val config = packageConfiguration.value | |||
| val s = streams.value | |||
| Package(config, s.cacheStoreFactory, s.log) | |||
| Package(config, s.cacheStoreFactory, s.log, Some(0)) | |||
|
The validator has checked the following projects, tested using dbuild, projects built on top of each other.
❌ The result is: FAILED |
|
A validation involving this pull request is in progress... |
|
The validator has checked the following projects, tested using dbuild, projects built on top of each other.
❌ The result is: FAILED |
|
The failure reminds of #3893 - should we reopen that one or is this different? |
|
The failure looks unrelated. Let me restart the job. |
|
A validation involving this pull request is in progress... |
|
btw test test failure shows a case where one has a subproject named |
|
The validator has checked the following projects, tested using dbuild, projects built on top of each other.
✅ The result is: SUCCESS |
|
A validation involving this pull request is in progress... |
|
The validator has checked the following projects, tested using dbuild, projects built on top of each other.
❌ The result is: FAILED |
|
Any update on this? Deterministic & reproducible build output would be highly useful, and make things like "nixification and caching of sbt projects' outputs" much simpler. |
|
I think it just needs a new release of IO. |
|
I forgot to mention that I published IO 1.4.0-M1 a while back - https://repo1.maven.org/maven2/org/scala-sbt/io_2.12/1.4.0-M1/ |
|
Interesting, that travis failure looks legitimate, looking into it Edit: found it, sbt/io#281 |
|
A validation involving this pull request is in progress... |
|
The validator has checked the following projects, tested using dbuild, projects built on top of each other.
❌ The result is: FAILED |
|
Closing this in favor of #5344 |
|
Thanks! |
This makes the build more deterministic.
This is a continuation of the work in sbt/io#58 , which I decided to get back into partly because Maven has been adding features to the core plugins, and it would be good to be on par :).
As discussed in sbt/io#58, we should be careful about the risk of breaking incremental builds - I haven't found any such issues yet though. Note that this PR only affects the timestamps of entries in jars: timestamps of classes on the filesystem and the filesystem timestamp of the jar itself are not affected.
Discussing this with @eed3si9n, there could be special-purposes build configurations that (for example in order to avoid deleting/creating many files) compile classes directly into a jar rather than first to individual files. I haven't seen this configuration yet, but I suspect it wouldn't use
Defaults.packageTask, but a customPackage/IOinvocation. Any custom build configuration that requires non-static timestamps can passNoneas thetimeparameter to keep the original behavior.This PR requires sbt/io#279