-
Notifications
You must be signed in to change notification settings - Fork 277
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
"classpath is corrupted: .scalafmt.conf" in 2.0.0-RC5 and 2.0.0-RC6 #1399
Comments
I'm seeing this as well in CI at work. It seems intermittent in my case, as if some machines get a corrupted cache and some don't.
|
Thanks for reporting! Hmm, I wonder if this has something to do with how the sbt plugin triggers parallel jobs 🤔 This might be fixed in #1384 |
Thanks for sharing this! :) Based on this, I think I was able to come up with a viable workaround (running this sequentially): |
This will fail the PR build if code isn't formatted properly. This won't fail builds done by bors, so that it fulfills only informational role for now. We might decide to enforce that for in bors builds later, depending on the results. Parallel execution is disabled for scalafmtCheckAll in CI. See scalameta/scalafmt#1399 for reasons why.
This will fail the PR build if code isn't formatted properly. This won't fail builds done by bors, so that it fulfills only informational role for now. We might decide to enforce that for in bors builds later, depending on the results. Parallel execution is disabled for scalafmtCheckAll in CI. See scalameta/scalafmt#1399 for reasons why.
This will fail the PR build if code isn't formatted properly. This won't fail builds done by bors, so that it fulfills only informational role for now. We might decide to enforce that for in bors builds later, depending on the results. Parallel execution is disabled for scalafmtCheckAll in CI. See scalameta/scalafmt#1399 for reasons why.
This will fail the PR build if code isn't formatted properly. This won't fail builds done by bors, so that it fulfills only informational role for now. We might decide to enforce that for in bors builds later, depending on the results. Parallel execution is disabled for scalafmtCheckAll in CI. See scalameta/scalafmt#1399 for reasons why.
This will fail the PR build if code isn't formatted properly. This won't fail builds done by bors, so that it fulfills only informational role for now. We might decide to enforce that for in bors builds later, depending on the results. Parallel execution is disabled for scalafmtCheckAll in CI. See scalameta/scalafmt#1399 for reasons why.
I'm getting this randomly as well, usually when trying to release:
|
Yeah, seems like I'm getting the same issue. I have opened another issue in case it's not: #1415 |
Just chiming in that I have seen the same issue on 2.0.0-RC7 and that limiting concurrency to 1 seems to be a workaround for now. |
I'm limiting concurrency to one in a multiproject and that doesn't fix the problem, at least for our project. Our project is quite complex though, we have something like 15 different projects managed as a monorepo in a single sbt configuration, all of them using scalafmt for formatting. |
Here's what I am doing to reduce the concurrency of import sbt._
import Keys._
import org.scalafmt.sbt.ScalafmtPlugin
import ScalafmtPlugin.autoImport._
object FixScalafmtPlugin extends AutoPlugin {
override def requires = ScalafmtPlugin
override def trigger = allRequirements
val ScalaFmtTag = ConcurrentRestrictions.Tag("scalafmt")
override def globalSettings: Seq[Def.Setting[_]] =
Seq(
concurrentRestrictions += Tags.limit(ScalaFmtTag, 1)
)
override def projectSettings: Seq[Def.Setting[_]] =
Seq(
scalafmtCheckAll := (scalafmtCheckAll.tag(ScalaFmtTag)).value,
Compile / scalafmtCheck := ((Compile / scalafmtCheck).tag(ScalaFmtTag)).value,
Test / scalafmtCheck := ((Test / scalafmtCheck).tag(ScalaFmtTag)).value,
)
} |
Hi, I released scalafmt-cli 2.0.0-RC8 and sbt-scalafmt 2.0.1 that contains #1384. This release might fix this issue. |
Hi! I've bumped to the above and they seem to have resolved the issue for me. https://drone.rchain-dev.tk/rchain/rchain/4254/3 I've seen scalafmt run correctly in CI multiple times, including an 8-way parallel run in here: The build failures above in 1 + 2 of the 8 + 8 jobs seems to be a different issue, and with sbt - not sbt-scalafmt plugin or scalafmt itself. Thank you! :) |
@ArturGajowy Thank you for reporting! |
I tried to add
scalafmtCheckAll
to our build after bumping to the latest version, but it results in the following. For some reason, this has only happened once or twice on my machine and from then seems to work.EDIT: I should probably mention that it happens consistently in our CI, which is blocking me from using scalafmt to guard the PRs...
To reproduce, you can checkout this PR: https://github.com/rchain/rchain/pull/2331/commits
See also the CI build in question:
https://drone.rchain-dev.tk/rchain/rchain/2683/3
Any ideas what might be wrong? How do I further diagnose that?
Thx!
The text was updated successfully, but these errors were encountered: