-
Notifications
You must be signed in to change notification settings - Fork 10
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
add sbt-reproducible-builds and fix lanucher builds #206
Conversation
Another go at apache#71/apache#80, might work now that apache#193 was fixed
.disablePlugins(MimaPlugin) | ||
.settings( | ||
name := "pekko-persistence-cassandra-launcher", | ||
Compile / managedResourceDirectories += (cassandraBundle / target).value, | ||
Compile / managedResources += (cassandraBundle / Compile / packageBin).value) | ||
Compile / unmanagedResources += (cassandraBundle / Compile / packageBin).value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is PR change, can you take a look? thanks @raboof
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does make sense as as those build results are 'unmanaged' from the perspective of the cassandra-launcher
build.
I might worry sbt wouldn't correctly pick up that changes to the bundle should trigger a rebuild of the launcher, but perhaps that's sufficiently guaranteed since cassandraBundle / Compile / packageBin
is still part of the graph.
In any case I don't think we expect many changes here, and CI shows it works well also when building 'from scratch'. I've also tried various experiments in sbt and didn't see any new/seriously problematic behavior.
For reference: I did notice that sbt clean
does not clear cassandra-bundle/target
, and it does not get rebuilt when it exists and you're building sbt cassandraLauncher/package
, even if you made changes to the definition of the bundler. That was all already the case on the main branch, though, so not a regression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks a lot for digging into this!
.disablePlugins(MimaPlugin) | ||
.settings( | ||
name := "pekko-persistence-cassandra-launcher", | ||
Compile / managedResourceDirectories += (cassandraBundle / target).value, | ||
Compile / managedResources += (cassandraBundle / Compile / packageBin).value) | ||
Compile / unmanagedResources += (cassandraBundle / Compile / packageBin).value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does make sense as as those build results are 'unmanaged' from the perspective of the cassandra-launcher
build.
I might worry sbt wouldn't correctly pick up that changes to the bundle should trigger a rebuild of the launcher, but perhaps that's sufficiently guaranteed since cassandraBundle / Compile / packageBin
is still part of the graph.
In any case I don't think we expect many changes here, and CI shows it works well also when building 'from scratch'. I've also tried various experiments in sbt and didn't see any new/seriously problematic behavior.
For reference: I did notice that sbt clean
does not clear cassandra-bundle/target
, and it does not get rebuilt when it exists and you're building sbt cassandraLauncher/package
, even if you made changes to the definition of the bundler. That was all already the case on the main branch, though, so not a regression.
Continue on the #205, resolves: #192
Jar results seem the same:
and the zipdiff report the same result: