Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deterministic Compilation / Reproducible Builds #405

Closed
heartsucker opened this issue Jul 19, 2017 · 9 comments
Closed

Deterministic Compilation / Reproducible Builds #405

heartsucker opened this issue Jul 19, 2017 · 9 comments
Assignees
Milestone

Comments

@heartsucker
Copy link

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.

@dragos
Copy link

dragos commented Jul 24, 2017

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.

@jvican
Copy link
Member

jvican commented Jul 24, 2017

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.

@retronym
Copy link
Member

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.

@adriaanm
Copy link
Contributor

adriaanm commented Jun 4, 2018

All scala/scala PRs for this are now merged.

@retronym
Copy link
Member

retronym commented Jun 4, 2018

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.

@johnynek
Copy link

johnynek commented Jun 4, 2018

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.

@SethTisue SethTisue modified the milestones: 2.13.0-M5, 2.13.0-RC1 Aug 7, 2018
@SethTisue
Copy link
Member

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

@retronym retronym modified the milestones: 2.13.0-RC1, 2.13.0-M5 Aug 21, 2018
@retronym
Copy link
Member

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

@SethTisue
Copy link
Member

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

raboof added a commit to raboof/sbt-reproducible-builds that referenced this issue Sep 27, 2018
With reproducibility features:
scala/scala-dev#405
raboof added a commit to raboof/sbt-reproducible-builds that referenced this issue Sep 27, 2018
With reproducibility features:
scala/scala-dev#405
raboof added a commit to raboof/dotty that referenced this issue Apr 28, 2022
This change makes sure non-repeated annotations are kept in the order
they were found in the source code.

The motivation is not necessarily to have them in the original order,
but to have them in an order that is deterministic across rebuilds
(potentially even across different machines), for reasons discussed
further in scala#7661 and the corresponding scala/scala-dev#405

I tried adding an 'integration test' in `tests/pos` to be picked up by
`IdempotencyCheck.scala`, but unfortunately couldn't reproduce the
nondeterminism that way, so didn't end up including it in this commit.

I didn't see an obvious place for a 'unit test' of this code, I'd be
happy to add one when someone can recommend a good place to put it.

This is basically the dotty equivalent of
scala/scala@954c5d3

Fixes scala#14743
raboof added a commit to raboof/dotty that referenced this issue Apr 28, 2022
This change makes sure non-repeated annotations are kept in the order
they were found in the source code.

The motivation is not necessarily to have them in the original order,
but to have them in an order that is deterministic across rebuilds
(potentially even across different machines), for reasons discussed
further in scala#7661 and the corresponding scala/scala-dev#405

I tried adding an 'integration test' in `tests/pos` to be picked up by
`IdempotencyCheck.scala`, but unfortunately couldn't reproduce the
nondeterminism that way, so didn't end up including it in this commit.

I didn't see an obvious place for a 'unit test' of this code, I'd be
happy to add one when someone can recommend a good place to put it.

This is basically the dotty equivalent of
scala/scala@954c5d3

Fixes scala#14743
raboof added a commit to raboof/dotty that referenced this issue Apr 28, 2022
This change makes sure non-repeated annotations are kept in the order
they were found in the source code.

The motivation is not necessarily to have them in the original order,
but to have them in an order that is deterministic across rebuilds
(potentially even across different machines), for reasons discussed
further in scala#7661 and the corresponding scala/scala-dev#405

An 'integration test' `Annotations.scala` was added in `tests/pos`
to be picked up by `IdempotencyCheck.scala`, but unfortunately I
haven't successfully reproduced the nondeterminism that way.

I didn't see an obvious place for a 'unit test' of this code, I'd be
happy to add one when someone can recommend a good place to put it.

This is basically the dotty equivalent of
scala/scala@954c5d3

Fixes scala#14743
raboof added a commit to raboof/dotty that referenced this issue Apr 28, 2022
This change makes sure non-repeated annotations are kept in the order
they were found in the source code.

The motivation is not necessarily to have them in the original order,
but to have them in an order that is deterministic across rebuilds
(potentially even across different machines), for reasons discussed
further in scala#7661 and the corresponding scala/scala-dev#405

Some integration tests were added in `tests/pos` to be picked up by
`IdempotencyCheck.scala`, but unfortunately I haven't successfully
reproduced the nondeterminism that way.

I didn't see an obvious place for a 'unit test' of this code, I'd be
happy to add one when someone can recommend a good place to put it.

This is basically the dotty equivalent of
scala/scala@954c5d3

Fixes scala#14743
raboof added a commit to raboof/dotty that referenced this issue Apr 28, 2022
This change makes sure non-repeated annotations are kept in the order
they were found in the source code.

The motivation is not necessarily to have them in the original order,
but to have them in an order that is deterministic across rebuilds
(potentially even across different machines), for reasons discussed
further in scala#7661 and the corresponding scala/scala-dev#405

Some integration tests were added in `tests/pos` to be picked up by
`IdempotencyCheck.scala`, but unfortunately I haven't successfully
reproduced the nondeterminism that way.

I didn't see an obvious place for a 'unit test' of this code, I'd be
happy to add one when someone can recommend a good place to put it.

This is basically the dotty equivalent of
scala/scala@954c5d3

Fixes scala#14743
bishabosha pushed a commit to dotty-staging/dotty that referenced this issue Oct 18, 2022
This change makes sure non-repeated annotations are kept in the order
they were found in the source code.

The motivation is not necessarily to have them in the original order,
but to have them in an order that is deterministic across rebuilds
(potentially even across different machines), for reasons discussed
further in scala#7661 and the corresponding scala/scala-dev#405

Some integration tests were added in `tests/pos` to be picked up by
`IdempotencyCheck.scala`, but unfortunately I haven't successfully
reproduced the nondeterminism that way.

I didn't see an obvious place for a 'unit test' of this code, I'd be
happy to add one when someone can recommend a good place to put it.

This is basically the dotty equivalent of
scala/scala@954c5d3

Fixes scala#14743
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants