Metals SNAPSHOT releases not published

[Filip Wiechowski]

Describe the bug

After I saw that the fix for the #6206 was merged into master branch (once again thanks for the quick solution!) I was eager to test it out, since the issue could be quite a pain to work with. 😅 However, it looks like the new SNAPSHOT builds are not being released, the CI "Release" step stops with the message: Error: [launcher] error during sbt launcher: java.lang.OutOfMemoryError: Java heap space. Not sure if it's just a coincidence or whether it's actually related to the changes in fe430b2, but just wanted to let you know, as somebody who likes to always use the latest version (and really wanting the aforementioned fix, not gonna lie). 😉

Expected behavior

SNAPSHOTs are pushed to Sonatype repository for newly merged commits.

Operating system

None

Editor/Extension

None

Version of Metals

1.2.2+80-b278ef9e-SNAPSHOT

Extra context or search terms

No response

[Tomasz Godzik]

Looks like scalafix is the reason for this:

java.lang.OutOfMemoryError: Java heap space
	at org.eclipse.jgit.internal.storage.file.PackIndexV2.<init>(PackIndexV2.java:95)
	at org.eclipse.jgit.internal.storage.file.PackIndex.read(PackIndex.java:101)
	at org.eclipse.jgit.internal.storage.file.PackIndex.open(PackIndex.java:67)
	at org.eclipse.jgit.internal.storage.file.Pack.idx(Pack.java:161)
	at org.eclipse.jgit.internal.storage.file.Pack.get(Pack.java:273)
	at org.eclipse.jgit.internal.storage.file.PackDirectory.open(PackDirectory.java:216)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openPackedObject(ObjectDirectory.java:393)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openPackedFromSelfOrAlternate(ObjectDirectory.java:356)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObjectWithoutRestoring(ObjectDirectory.java:346)
	at org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObject(ObjectDirectory.java:331)
	at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:132)
	at org.eclipse.jgit.revwalk.RevWalk.getCachedBytes(RevWalk.java:1119)
	at org.eclipse.jgit.revwalk.RevCommit.parseHeaders(RevCommit.java:126)
	at org.eclipse.jgit.revwalk.RevWalk.markStart(RevWalk.java:308)
	at org.eclipse.jgit.api.LogCommand.add(LogCommand.java:343)
	at org.eclipse.jgit.api.LogCommand.add(LogCommand.java:180)
	at org.eclipse.jgit.api.LogCommand.call(LogCommand.java:133)
	at scalafix.internal.sbt.JGitCompletion.$anonfun$x$1$1(JGitCompletions.scala:29)
	at scalafix.internal.sbt.JGitCompletion$$Lambda$9375/0x00007ec7[2180](https://github.com/scalameta/metals/actions/runs/8298008580/job/22710386419#step:4:2181)8600.apply(Unknown Source)
	at scala.util.Try$.apply(Try.scala:213)
	at scalafix.internal.sbt.JGitCompletion.<init>(JGitCompletions.scala:29)
	at scalafix.internal.sbt.ScalafixCompletions.gitDiffParser$lzycompute(ScalafixCompletions.scala:119)
	at scalafix.internal.sbt.ScalafixCompletions.gitDiffParser(ScalafixCompletions.scala:118)
	at scalafix.internal.sbt.ScalafixCompletions.parser(ScalafixCompletions.scala:186)
	at scalafix.sbt.ScalafixPlugin$.$anonfun$scalafixInputTask$4(ScalafixPlugin.scala:357)
	at scalafix.sbt.ScalafixPlugin$$$Lambda$8642/0x00007ec7215f5600.apply(Unknown Source)
	at scala.Function1.$anonfun$compose$1(Function1.scala:49)
	at scala.Function1$$Lambda$1172/0x00007ec7204dee78.apply(Unknown Source)

it should not be run at all :O

[Tomasz Godzik]

Raised an issue in scalafix since I am not sure what is going on scalacenter/scalafix#1965

[Filip Wiechowski]

Thanks for looking into it! 👍

[Tomasz Godzik]

Updated to the lastes scalafix and the issue should be gone