fix failing sbt 0.13 builds in 2.12 build about community-build HOT 2 CLOSED

I was thrown off because this was a PR run, but it turned out not to have anything do with the Scala version number bump, it's just that bumping the version number was what triggered dbuild to stop using cached artifacts in the target-0.9.20 directory and retrieve new ones from our Artifactory (scala-ci.typesafe.com/artifactory)

so the root cause turned out to be that our Artifactory had a bad JAR in cache, dating back to April 7, so this was an aftereffect of http://github.com/sbt/sbt/issues/7202 — it's still not fully clear to me why the bad artifact didn't cause any failures on April 7. perhaps some build did fail on April 7, perhaps one I ran locally, and I didn't notice, or perhaps there were multiple failures in some run, or idk what

from community-build.

only the 2.12 build was affected, because only sbt 0.13 was affected, and the 2.13 build is all sbt 1 these days

only dbuild was affected, the JAR involved only comes into the picture specifically when running inside dbuild

as soon as I started suspecting April 7 as the cause, I went into our Artifactory and did "Zap cache" to all of the virtual repositories

since at that point I didn't yet know what the bad artifact was

but it turns out that "Zap cache" doesn't really do anything. or didn't in this case

so I actually had to identify the bad artifact, and then find it in the artifact browser and hit "Delete"

(one hopes we don't have any other bad artifacts in cache)

it's annoying that Artifactory will happily cache something that isn't a JAR — this was one of the reasons the April 7 event was so pernicious. and it's doubly annoying that our open-source plan with JFrog caused HTML pages to be served as JARs, rather than 404ing or whatever

I do wonder if there's some setting we don't have enabled that would have prevented the caching of bad artifacts, at least

anyway

commands like these were helpful for identifying the bad artifact locally:

find ~/.dbuild -name \*.jar | xargs -L 1 zip -T | grep -v OK\$
find ~/.ivy2 -name \*.jar | xargs -L 1 zip -T | grep -v OK\$
find ~/.m2 -name \*.jar | xargs -L 1 zip -T | grep -v OK\$
find ~/cb2 -name \*.jar | xargs -L 1 zip -T | grep -v OK\$

one of the reasons this was so hard to find is that sbt 0.13 uses Scala 2.10, and when a corrupt JAR is on the classpath, 2.10 doesn't give a helpful error message identifying the bad JAR

the actual bad JAR was target-0.9.20/project-builds/sbt-testng-6e0b39dd34b5a92f446e932bbe5883d380460a6c/.dbuild/topIvy/ivy2/cache/org.apache.maven.resolver/maven-resolver/jars/maven-resolver-1.1.0.jar , served from https://scala-ci.typesafe.com/ui/repos/tree/General/sbt-plugin-releases-cache%2Forg.apache.maven.resolver%2Fmaven-resolver%2F1.1.0%2Fjars%2Fmaven-resolver.jar

from community-build.