Hi everyone, I got the same issue for my current work webapps (not at archive level but docker image level - I'm using jib and it enforces a "constant" timestamp). I solved it by using last commit timestamp as file timestamp. Indeed it can miss a "strict" cache hit but globally it is a good compromise and guess it can be reused for reproducible builds. In any case, a project using a scm will be reproducible only regarding a commit so it sounds like the least bad compromise. wdyt?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le sam. 18 avr. 2020 à 10:08, Hervé BOUTEMY <[email protected]> a écrit : > Le vendredi 17 avril 2020, 22:20:11 CEST Michael Osipov a écrit : > > Am 2020-04-17 um 22:00 schrieb [email protected]: > > > Reproducible Builds is now implemented in many plugins: it's time to > work > > > on reproducible war files. > > > > > > I created MWAR-432 issue and implemented classical Reproducible jar > output > > > in corresponding branch. > > > > > > But in our discussion in november [1], an issue was reported for > unchanged > > > timestamp in SNAPSHOTs war regarding Tomcat detection algorithm of > > > changed content. > > If you are referring to Tomcat's ETag calculation, it uses both > > timestamp and file size. The weak ETag will change as soon as the fize > > size changes. Of course, this is a problem because if the file changes, > > but the content length does not, the ETag won't. > > > > From a Tomcat perspective this does not matter because every deployment > > has its own class loader and in-memory cache. > > > > From a client's one, yes. The client will receive a 304 and read from > > cache although the file has been changed. > > > > > Should we just disable reproducible wars for SNAPSHOTs and enable it > only > > > for releases? Should we add a boolean option for people to decide > whether > > > they want reproducible SNAPSHOTs? > > It should be a user choice. > > > > > Is there any idea on how we could manage output timestamp for > SNAPSHOTs? > > > > You could do baselining: > > > > * All files which have been changed before output timestamp, will have > > output timestamp > > * All other files will retain their timestamp. > > > > A changed file will be immediately reflected by its new timestamp. > that means "not reproducible", then if we're at that level, let's just not > apply any timestamp calculations: it's just disabling reproducible output > for > SNASPHOTs > > > > > Please also ask on [email protected], I might have missed other use > cases. > good idea, thank you > > > > > Michael > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
