-
Notifications
You must be signed in to change notification settings - Fork 506
Misleading "Unable to bump version" is logged when the version was already bumped #2906
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
…nce the same val version
I looked into this a bit more today, running scala-steward on a private repo. I noticed the following interesting behavior: I created an empty project with a build.sbt like this: ThisBuild / version := "0.1.0-SNAPSHOT"
ThisBuild / scalaVersion := "2.13.10"
lazy val circeVersion = "0.13.0"
lazy val root = (project in file("."))
.settings(
name := "scala-steward-2906",
libraryDependencies ++= Seq(
"io.circe" %% "circe-core" % circeVersion,
"io.circe" %% "circe-parser" % circeVersion
)
) When I run scala-steward with no .scala-steward.conf, it correctly updates the Then I added a .scala-steward.conf to group the updates:
In this case, it still correctly updates the version, but it does print the warning:
I'll do some more debugging and see if I can make a PR to resolve this. |
I was able to replicate this behavior in a "real" project. For now I think I'm just going to avoid the |
I added some println debugging in my fake circe project, on this commit: 39b618f. Specifically in the findUpdateReplacements and applyUpdateReplacements methods in EditAlg. Below are the respective logs. I pulled out the parts that looked relevant, but also attached the full log files (incl. many debug lines). With no grouping and no warning:
Full logs: no-warning.log With grouping and with warning:
Full logs: warning.log |
The main difference I see is in the update parameter passed to findUpdateReplacements:
|
So there might be two questions here:
|
One last though, and then I have to wrap up my investigation soon: I added another println to
So, in this case, the Grouped update and the ForGroupId update are actually equivalent, but they are treated differently based on the grouping. That difference seems to originate in |
So the reason this happens is because |
Also for this, if we generate a |
Thanks for the insight. I'll have to re-read a few times to make sure I follow. In the meantime, do you see any way to avoid the incorrect warnings? |
🤔 Nothing that would require refactors here and there so |
When there are two deps both referencing the same val for their versions, the second update will print a misleading warning. I would expect that there is no warning, since the second update was, practically speaking, applied.
I'll create a PR to reproduce this.
The text was updated successfully, but these errors were encountered: