Include 'reproducible builds' sbt plugin #26546
Conversation
This does 2 things: * publish a 'buildinfo' report along with the project artifacts to describe the build context and parameters * post-process the jars to remove 'arbitrary' differences, such as jar file ordering and timestamps. This makes it easier to detect and explain when 2 builds of the same source don't produce a bit-per-bit identical result. This for example can improve our confidence that our distribution pipeline has not been compromised.
akka-ci
added
validating
|
Test PASSed. |
project/OSGi.scala
Outdated
|
|
||
| object OSGi { | ||
|
|
||
| // The included osgiSettings that creates bundles also publish the jar files | ||
| // in the .../bundles directory which makes testing locally published artifacts | ||
| // a pain. Create bundles but publish them to the normal .../jars directory. | ||
| def osgiSettings = defaultOsgiSettings ++ Seq( | ||
| Compile / packageBin := OsgiKeys.bundle.value, | ||
| Compile / packageBin := ReproducibleBuildsPlugin.postProcessJar(OsgiKeys.bundle.value), |
There was a problem hiding this comment.
Isn't it weird to sneak it in here in the OSGi config or does it have to be here to know that it happens after the OSGi bundle task
There was a problem hiding this comment.
ReproducibleBuildsPlugin.postProcessJar is normally injected into Compile/packageBin automatically by the reproducible-builds plugin. Here we replace the Compile/packageBin task wholesale with the OSGi bundle, so we need to 're-introduce' the ReproducibleBuildsPlugin.postProcessJar explicitly. We could do it elsewhere but I think that would make it even harder to follow. I'll add a comment explaining this though.
There was a problem hiding this comment.
Couldn't it be it's own autoplugin and just express the ordering by depending on the OSGi autoplugin though?
It includes some system properties (like |
akka-ci
added
validating
|
Test PASSed. |
This does 2 things:
the build context and parameters
ordering and timestamps.
This makes it easier to detect and explain when 2 builds of the same source
don't produce a bit-per-bit identical result. This for example can improve
our confidence that our distribution pipeline has not been compromised.