-
-
Notifications
You must be signed in to change notification settings - Fork 360
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
Peculiar cache behavior for external modules #2419
Comments
Seems like it could be related to mill/runner/src/mill/runner/MillBuildBootstrap.scala Lines 132 to 140 in df86a07
It seems to me that that logic relies on at least one meta-build to be present in Maybe instead of |
Yeah, that seem to fix the issue for me. Any idea, how to test this? I opened PR #2421 to address it. |
Not sure about testing TBH. This misbehavior only happens when the Mill version changes, and we don't really have any precedence for using different Mill versions in our tests. All our tests use Mill build from HEAD |
It's probably ok to merge the linked PR as is, as it appears to fix my concrete case. Maybe, we can come up with some shell or Scala scripting doing the necessary version bumps and building two different mill versions, in the spirit of our bootstrap tests. NB: We also have issues with handling a Mill version change in a running server, which we could approach this time with some tests. I fixed most of them manually in the past, but it was a time consuming process, and it partially regressed when we switched our rpc library to junixsocket. |
In the process of fixing regressions in the BSP module (after the
remove-ammonite
) I noticed some strange behavior which is probably caused by some stale caches.When I run a newer Mill version, the
bspWorkerLibs
target of the externalmill.bsp.BSP
module uses a stale cache value. I think, previously, it was re-computed. The default value of that target is computed inside of that target. As the external module is part of the classpath, a change was tracked by the classpath sig and resulted in an invalidation (I think). It looks like somehow we no longer track a change in the classpath.The text was updated successfully, but these errors were encountered: