-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Upgrade to sbt 1.4.4 #10498
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
Upgrade to sbt 1.4.4 #10498
Conversation
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.
Is there a reason for the change to dotty-cps-async? It looks like the HEAD of the submodule has been pointed away from master which was updated earlier today by the merge of #10486.
It seems that much of the test logging in the community build is now suppressed: the log for part a has gone from ~15k to ~6k lines, and part b from ~13k to ~2k lines. I presume this is expected/intentional.
I'm pleasantly surprised by the performance improvement from the use of batch mode for the sbt scripted tests. On my local machine, running time was reduced from 35 to 8 minutes!
I was also a bit surprised not to see [test_sbt] in the body of the pull request message. ;-)
Theo following projects failed to compile: minitest, scopt, squants and stdlib213: - Scopt and squants still do not support Scala 3 upstream, I decided to drop them because the alternatives (staying with an old fork and cherry-picking changes, or continuously rebasing our fork on top of upstream) requires too much on-going maintenance work, we can add them back when they officially support Scala 3. - Minitest was upgraded to the latest upstream commit (I made a PR upstream to support 3.0.0-M2), at the same time I enabled running the tests (both JVM and JS) of minitest instead of just compiling it. - The new minitest required a new scalacheck, upgrading scalacheck broke other projects in the community build which depended on an old version of it. I fixed the issue by using `dependencyOverrides` to force all projects to use the same version of scalacheck, we can use this mechanism for other projects upgrade in the future. - stdlib213 was rebased on the latest upstream commit, I opened a PR with the necessary changes so we don't need to keep a fork anymore: scala/scala#9345 Some of our sbt scripted tests started failing after upgrading sbt, I traced this to an unintentional behavior change in sbt which now uses always run scripted tests in batch mode (sbt/sbt#5913 (comment)). The next two commits add batch modes support to our scripted tests by porting fixes made in sbt itself when it switched its own tests to batch modes a while ago. The good news is that the batch mode makes the scripted tests much faster.
Port sbt/sbt@927910a needed because sbt 1.4 uses batch mode for scripted tests.
Port of sbt/sbt@dc04892 needed because sbt 1.4 uses batch mode for scripted tests.
da76644
to
99e2b4e
Compare
Nope, looks like I messed up a rebase, will fix, thanks for the catch.
Yeah I tried it on a personal fork so I didn't have to but it would have been a good use for it. :) |
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.
Otherwise LGTM.
assert(a.compilations.allCompilations.size == expectedIterationsNumber, | ||
"a.compilations.allCompilations.size = %d (expected %d)".format(a.compilations.allCompilations.size, expectedIterationsNumber)) | ||
// Reset compiler iterations, necessary because tests run in batch mode | ||
val recordPreviousIterations = taskKey[Unit]("Record previous iterations.") |
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 task is duplicated throughout the codebase. It's fine to get it in to unblock other stuff dependent on it, but we should create an issue to DRY it out in the future.
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.
Maybe a compiler plugin would help here?
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.
The problem is to figure out how to inject a compiler plugin in the scripted tests, one way would be to have it as a separate project that we publish before we run the scripted tests, but that's pretty heavy-weight.
fyi @eed3si9n @eatkins... very cool to see both Scala 2 and Scala 3 on latest sbt again (cf scala/scala#9340, scala/scala#9202) |
Theo following projects failed to compile: minitest, scopt, squants and
stdlib213:
drop them because the alternatives (staying with an old fork and
cherry-picking changes, or continuously rebasing our fork on top of
upstream) requires too much on-going maintenance work, we can add them
back when they officially support Scala 3.
upstream to support 3.0.0-M2), at the same time I enabled running the
tests (both JVM and JS) of minitest instead of just compiling it.
other projects in the community build which depended on an old version
of it. I fixed the issue by using
dependencyOverrides
to force allprojects to use the same version of scalacheck, we can use this
mechanism for other projects upgrade in the future.
with the necessary changes so we don't need to keep a fork anymore:
Upgrade to Scala 3.0.0-M2 scala#9345
Some of our sbt scripted tests started failing after upgrading sbt, I
traced this to an unintentional behavior change in sbt which now uses
always run scripted tests in batch
mode (sbt/sbt#5913 (comment)).
The next two commits add batch modes support to our scripted tests by
porting fixes made in sbt itself when it switched its own tests to batch
modes a while ago. The good news is that the batch mode makes the
scripted tests much faster.