updating to sbt-scalafix 0.9.18 causes crash #1196
Comments
|
Thanks for the report @philwalk! |
|
No problems reported by |
|
+1 getting the same error in only one of our sbt multi-project build (with latest sbt eco-system) |
|
@philwalk @anilkumarmyla any chance you can share your build or at least the relevant parts (Scalafix settings & plugins activated with their version) ? A small build where you can reproduce the problem world be ideal. |
|
The strange thing is it happens only in our CI build and only for a sbt multi-project build (other projects worked fine), attempting to reproduce this locally on mac or docker+linux fail (CI runs on linux). Another strangeness is the |
|
@anilkumarmyla interesting. Are you also using sbt 1.3.12? |
|
Potential changes that could impact sbt initialization: scalacenter/sbt-scalafix@2ca68e4#diff-b6db8e3499369917214568aee2dd0960R116-R132. |
|
Nice to meet you. The existence of the I'm using sbt-1.3.12 but the same applies to 1.3.13. The OS is Arch linux. Can't reproduce on Windows (msys2). A minimum set of steps to reproduce: // build.sbt
lazy val service1 = project# project/build.properties
sbt.version=1.3.13// project/plugins.sbt
addSbtPlugin("ch.epfl.scala" % "sbt-scalafix" % "0.9.18")$ git init
Initialized empty Git repository in <snip>
$ sbt
[info] welcome to sbt 1.3.13 (Oracle Corporation Java 1.8.0_252)
<snip>
[error] java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.CompletableFuture$AsyncSupply@448eccc7 rejected from java.util.concurrent.ThreadPoolExecutor@5e4a5ee2[Running, pool size = 2, active threads = 2, queued tasks = 0, completed tasks = 0]
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?Adding [error] org.eclipse.jgit.api.errors.NoHeadException: No HEAD exists and no explicit starting revision was specified
[error] Use 'last' for the full log.Creating a commit resolves it. |
|
Great job isolating the problem @matil019! I am working on a fix. |
|
Wow, glad we have a minimal build that reproduces the problem, my build is quite extensive ... |
|
I have good hopes that scalacenter/sbt-scalafix#141 fixes the problem. Once it's reviewed & merged, will you be able to try a SNAPSHOT of |
|
I'll test the SNAPSHOT as soon as it's ready |
|
Here's a bit more about the problem I'm having with scala 2.13.3, in case it's related. |
|
Also, FWIW, my .git workspace has had thousands of commits, so the scalacenter/sbt-scalafix#141 referenced condition doesn't apply:
|
|
thanks for the assistance, BTW! |
I guess we have several problems then. The fix might still work as it basically degrade gracefully if looking up the last commits via jgit fails. |
Latest sbt 1.3.13 |
|
@philwalk |
|
The SNAPSHOT version fails in exactly the same way as before, same stackdump, etc. A possible additional clue: when I work around the problem (by renaming .git to dot-git), I run into this error: |
|
Here's a minimal project that demonstrates the problem in windows: https://github.com/philwalk/scalafix-bug |
|
I've tried to minimize as all, stripped down the multi-project into a single project (deleting everything except the last and flattening the project) and it stops failing. Need to find the right balance to reproduce it |
|
@anilkumarmyla did you try |
|
I've also hit this For me, I was hitting this issue in my sbt-dynver test suite, which was creating independent https://github.com/dwijnand/sbt-dynver/pull/165/files Perhaps there's a natural or reasonable place in sbt-scalafix to do a similar one-off seed. |
|
Just hit the same error, not going to post the stacktrace as it seems to be identical to the previously posted one. |
|
@dwijnand thanks a lot for the pointers! I think I have a good lead on the problem: among other things, the scalafix input task parser (which eagerly triggers a lookup of the last commits at sbt init) is no longer properly cached in 0.9.18, so usage of JGit grows with the number of sub-projects, which stresses the static thread pool you mentioned. scalacenter/sbt-scalafix@9a283a7 should address it. |
|
Sorry, I didn't mean to close this but the merge of the tentative fix did it automatically. Can you try |
|
0.9.18+10-bffce56d-SNAPSHOT no longer crashes on startup, very good! I'm not able to use this SNAPSHOT due to other problems. I'll try to file a bug report later today if it hasn't already filed. |
|
@philwalk good! the failure is "expected", See doc in https://scalacenter.github.io/scalafix/docs/users/installation.html#settings-and-tasks. You can unfortunately expect more of this kind of failures in the coming weeks/months, until all existing rules are cross-built (something that is only possible/asdvised for a few weeks). |
|
closing this as sbt-scalafix 0.9.18-1 is out |
|
Updating to 0.9.18-1 fixed our issue, thanks for the quick fix @bjaglin |
|
Thanks for the very quick updates! |
|
Unfortunately, scala-steward ignores this plugin update since it cannot understand the version format 😢 |
SBT wouldn't start with 0.9.18; see scalacenter/scalafix#1196
Not just scala-steward, but sbt-updates too. Why not just use 0.9.18.1? |
Good question. I followed what was done in the past (https://github.com/scalacenter/sbt-scalafix/releases/tag/v0.9.15-1) without challenging the pattern. @olafurpg any objection to tag a 0.9.18.1? Or maybe a 0.9.18.2 to prevent confusion, now that there are new commits on master anyway. |
|
Actually, looking at https://github.com/rtimush/sbt-updates/blob/0.5.1/src/main/scala/com/timushev/sbt/updates/versions/Version.scala (used also by scala-steward), I am not sure x.x.x.x is any better than x.x.x-x. So I am leaning towards a 0.9.19 For the record. #1146 is coming soon so we don't have to deal with this in the future. |
|
Oh lol. :) Thanks for taking a look into that. The past can be what it already is, it might be a good plan to come up with a versioning scheme that's a bit friendlier to these tools, and start using it from 1.0 onwards (seeing as it's coming soon IIRC). |
|
Scala Steward isn't using sbt-updates anymore and would create PRs for 0.9.18 to 0.9.18.1. It hasn't created PRs for 0.9.18-1 since it ignores versions with a hyphen if the current version does not contain one. Update: scala-steward-org/scala-steward#1148 explains why it does that. |
|
oh, thanks for chiming-in @fthomas - my bad, I missed https://github.com/fthomas/scala-steward/pull/1287/files. |
|
I think we can release 0.9.19. I like the idea of keeping this kind of versioning was ( |
After updating to the newer version in project/plugins.sbt:
addSbtPlugin("ch.epfl.scala" % "sbt-scalafix" % "0.9.18") // no problems with "0.9.17"Also see the same (or quite similar) result running with java 1.8.
The text was updated successfully, but these errors were encountered: