scm does not work cause one common use case is to rebuild from source the same artifacts (debian rebuild from source AFAIK, even java apps) since scm can be "proxied", copied etc then the source can differ and therefore commits can be differents but the content can be the same this is why jib uses epoch+1s to enforce reproducibility. that said once you have the timestamp the code is the same so let's not block on that, worse case we would enable to plug a value resolver with a few default strategy. this is not the central part of the feature IMHO.
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 dim. 29 sept. 2019 à 19:58, Tibor Digana <tibordig...@apache.org> a écrit : > yes Hunter, exactly this was one possibility. > The names of the property can be just like in the HTTP Headers: > Last-Modified > If-Modified-Since -> maybe here can be also the commit hash, not only time > in millis/UTC > ETag > > and every module may have different value ;-) then. and then the SCM... has > to resolve " If-Modified-Since " to the TIME. > The missing "..." is some layer useful in the incremental build too. >
