Revert to sbt 0.13.2

[adriaanm]

sbt 0.13.5 broke a hack in our release scripts
(Confirmed by successful run using v1.0.1, which was on 0.13.1:
https://scala-webapps.epfl.ch/jenkins/job/scala-release-2.11.x/139/
previous builds have been red.)

Let's revert until we can come up with a fix for the script.

review by @gourlaysama, /cc @lrytz

[gkossakowski]

What's the hack and why is it broken in sbt 0.13.5?

[adriaanm]

It's related to the cyclic dependency in documenting the parsers with scaladoc that depends on the parsers: https://github.com/scala/jenkins-scripts/blob/master/job/scala-release-2.11.x#L183

[gkossakowski]

Thanks. LGTM.

[gourlaysama]

LGTM.

It's sad that we don't see the output of each sbtBuild in the jenkins job's console output, that would help.

[adriaanm]

True, the logs are archived as artifacts of the build. I split them out to make it easier to see errors at the script-level, since build errors should be rare in this job.

[gourlaysama]

Oh ok. But builds that failed to build parser-combinators, like this one, don't have the build and resolution logs in the build artifacts.

[adriaanm]

You're right :-) I came to the same conclusion as you just did when looking into this, so I changed the configuration to archive the logs.

[gourlaysama]

So this hasn't changed anything, the release job still fails: https://scala-webapps.epfl.ch/jenkins/job/scala-release-2.11.x/140/

But now we have the failure in the logs (an error publishing, "destination file exists and overwrite == false"). Also, the script seems to build the v1.0.2 tag, not master.

[adriaanm]

Yeah, that's probably why. @lrytz, could you take a look at building master
for this one in the release script?

On Thursday, July 31, 2014, Antoine Gourlay [email protected]
wrote:

So this hasn't changed anything, the release job still fails:
https://scala-webapps.epfl.ch/jenkins/job/scala-release-2.11.x/140/

But now we have the failure in the logs (an error publishing, "destination
file exists and overwrite == false"). Also, the script seems to build the
v1.0.2 tag, not master.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[lrytz]

sure, i'll have a look once i'm back (in a week from now)

[lrytz]

actually, the fact that the script builds the tag of parser-combinators is by design. the problem is the generated version. for xml, we get:

[info] Wrote /localhome/jenkins/c/workspace/scala-release-2.11.x/scala-xml/target/scala-2.11.3-50167e3-nightly/scala-xml_2.11.3-50167e3-nightly-1.0.2.pom

note the 50167e3-nightly in the version. for parser combinators:

[info] Wrote /localhome/jenkins/b/workspace/scala-release-2.11.x/scala-parser-combinators/target/scala-2.11/scala-parser-combinators_2.11-1.0.2.pom

[gourlaysama]

Interesting. It's like the set every scalaVersion := "2.11.3-50167e3-nightly" in the script doesn't do anything...

[gourlaysama]

Actually, it doesn't do anything, even locally:

[info] Loading global plugins from /home/gourlaysama/.sbt/0.13/plugins
[info] Loading project definition from /home/gourlaysama/dev/scaladev/scala-parser-combinators/project
[info] Set current project to scala-parser-combinators (in build file:/home/gourlaysama/dev/scaladev/scala-parser-combinators/)
> set every scalaVersion := "3.42-whatever"
[info] Defining */*:scalaVersion
[info] The new value will be used by */*:crossScalaVersions, */*:scalaBinaryVersion
[info] Reapplying settings...
[info] Set current project to scala-parser-combinators (in build file:/home/gourlaysama/dev/scaladev/scala-parser-combinators/)
> set version := "1.0.2-DOC"
[info] Defining *:version
[info] The new value will be used by *:isSnapshot, *:osgiBundleVersion and 8 others.
[info]  Run `last` for details.
[info] Reapplying settings...
[info] Set current project to scala-parser-combinators (in build file:/home/gourlaysama/dev/scaladev/scala-parser-combinators/)
> clean
[success] Total time: 0 s, completed Aug 8, 2014 4:29:57 PM
> doc
[warn] Credentials file /home/gourlaysama/.ivy2/.credentials does not exist
[info] Updating {file:/home/gourlaysama/dev/scaladev/scala-parser-combinators/}scala-parser-combinators...
[info] Resolving org.scala-lang#scala-compiler;2.11.1 ...
[warn] circular dependency found: org.scala-lang.modules#scala-parser-combinators_2.11;1.0.2-DOC->org.scala-lang#scala-compiler;2.11.1->org.scala-lang.modules#scala-parser-combinators_2.11;1.0.1
[info] Resolving jline#jline;2.11 ...
[info] Done updating.
[info] Main Scala API documentation to /home/gourlaysama/dev/scaladev/scala-parser-combinators/target/scala-2.11/api...
model contains 62 documentable templates
[warn] /home/gourlaysama/dev/scaladev/scala-parser-combinators/src/main/scala/scala/util/parsing/combinator/Parsers.scala:622: Could not find any member to link for "scala.collection.Iterable".
[warn]   /** A parser that matches only the given [[scala.collection.Iterable]] collection of elements `es`.
[warn]   ^
[warn] /home/gourlaysama/dev/scaladev/scala-parser-combinators/src/main/scala/scala/util/parsing/combinator/RegexParsers.scala:19: Could not find any member to link for "scala.Char".
[warn] /** The ''most important'' differences between `RegexParsers` and
[warn] ^
[warn] two warnings found
[info] Main Scala API documentation successful.
[success] Total time: 11 s, completed Aug 8, 2014 4:30:09 PM

The same thing in scala-swing fails.

[gourlaysama]

And reverting to sbt 0.13.2 fixes the problem. Except you can't alter the tag, so the only solution I see is to change the jenkins script to run sbt -sbt-version 0.13.2 <everything else>.

[paulp]

In case you missed it. sbt/sbt#1430

[lrytz]

@paulp thanks for the link, had not seen it.

@gourlaysama i changed the script to force 0.13.2 in scala/jenkins-scripts@a814ca0. You can therefore change build.properties back to 0.13.5 in the scala-parser-combinators repo, if you like.