Scala-dev: Deterministic Compilation / Reproducible Builds

Created on 19 Jul 2017  路  9Comments  路  Source: scala/scala-dev

This issue is being opened in response to this thread.

I want to have reproducible artifacts output from scalac and sbt so that I can:

  1. Have multiple, independent CI servers generate a build, sign it, and require multiple signatures for any artifact to be valid later in a pipeline
  2. Have independent sources be able to compile and verify that the output JAR / class files are identical to what they compiled locally

Because this could be complicated by faffing about too much with a build.scala like embedding the current time somewhere, let's assume that not all builds will be reproducible and that doing so might require minimal tweaking.

It would be a stretch to require incremental compilation to be reproducible, so what would be sufficient is that any sbt clean compile outputs the exact same things.

compiler determinism

Most helpful comment

I am really excited about this! We are using scalac with bazel and doing distributed caching (sharing build artifacts across CI runs and also from developer laptops). Cases like these where we had no reproducibility killed the cache (in fact we removed uses of quasi-quotes to improve matters).

I really appreciate this work.

All 9 comments

I'm afraid this ticket is not going to be very actionable since it falls between Sbt and Scala.

In my opinion the output of the compiler should be deterministic regardless of full vs incremental builds. Incremental compilation is not even a concept in the compiler: scalac simply takes a set of sources and compiles them, without any knowledge about what constitutes a full project. From the point of view of the compiler only the command line arguments are relevant.

In the current setup, assuming Sbt is sorting source files prior to sending them to scalac, full builds would be deterministic, but I doubt we can close the ticket in confidence.

I'll be commenting in the original Discourse thread about reproducibility in Zinc and some of my insights on how to achieve it. It's something I'm focusing on, and others volunteers are too. So far, there's progress.

I have collected some definitions of "stability" and test cases that show where we do fail to meet the strict definition (same output regardless of source file order or partial compilation of subsets of files). I'm working on fixing those at the moment.

All scala/scala PRs for this are now merged.

I'll do some followup work to run the resulting 2.13.x with scalac-stability-check.sh over a few code bases to see if there are any more moles to whack.

I am really excited about this! We are using scalac with bazel and doing distributed caching (sharing build artifacts across CI runs and also from developer laptops). Cases like these where we had no reproducibility killed the cache (in fact we removed uses of quasi-quotes to improve matters).

I really appreciate this work.

@retronym is this done as of M5, or does work remain for RC1?

I'll mark it as done for M5. More real world testing might trigger followup work, but all the known problems are solved.

okay, I'll include it in the M5 release notes

Was this page helpful?
0 / 5 - 0 ratings