Repository navigation
Selectively disable reproducibility check on build - #195
Conversation
We add a `reproducibility-check-enabled` option to the reusable build that will allow us to turn off the reproducibility check on certain builds. While the reproducibility check might detect some problems in a release build, IMHO it only increases the build time in most builds. Reproducibility problems are usually rare and are mostly due to the introduction of additional plugins. Also note that some kinds of reproducibility problems can only be detected by running the build on a **different** machine. We already encountered problems that only depended on the absolute path of the folder, where the build runs.
|
I think it is okay to confine this to release-specific branches.
I don't agree with this sentiment. I think our reproducibility definition is unnecessarily broad: all JDK vendors, all OS'es, etc. We can specialize on a certain setup: Zulu, Linux, x64. If the community cares about reproducibility on a certain other configuration, they are always more than welcome to contribute and maintain it. |
The reproducibility failure I have in mind generated different builds from |
2 participants
This PR is against the
develocitybranch.We add a
reproducibility-check-enabledoption to the reusable build that will allow us to turn off the reproducibility check on certain builds.While the reproducibility check might detect some problems in a release build, IMHO it only increases the build time in most builds.
Reproducibility problems are usually rare and are mostly due to the introduction of additional plugins.
Also note that some kinds of reproducibility problems can only be detected by running the build on a different machine. We already encountered problems that only depended on the absolute path of the folder, where the build runs.