Some cleanups in the build.

Author: lrytz

.travis.yml

@@ -22,6 +22,7 @@ stages:
   - name: publish
     if: type != pull_request
 
+# see comment in `bootstrap_fun` for details on the procedure
 # env available in each stage
 #  - by travis config (see below): secret env vars
 #  - by `common` script: WORKSPACE, IVY2_DIR, SBT_CMD, integrationRepoUrl

admin/init.sh

@@ -1,5 +1,4 @@
-#!/bin/bash
-
+#!/bin/bash -e
 
 sensitive() {
   perl -p -e 's/\$\{([^}]+)\}/defined $ENV{$1} ? $ENV{$1} : $&/eg' < files/credentials-private-repo > ~/.credentials-private-repo
@@ -12,14 +11,9 @@ sensitive() {
 # don't let anything escape from the sensitive part (e.g. leak environment var by echoing to log on failure)
 sensitive >/dev/null 2>&1
 
-# pgp signing doesn't work without public key??
-gpg --keyserver pgp.mit.edu --recv-keys 0xa9052b1b6d92e560
-
 # just to verify
 gpg --list-keys
 gpg --list-secret-keys
 
 mkdir -p ~/.sbt/0.13/plugins
 cp files/gpg.sbt ~/.sbt/0.13/plugins/
-
-export sbtCmd=$(which sbt)

scripts/bootstrap_fun

@@ -1,3 +1,71 @@
+# Bootstrap procedure
+#  - determine scala version
+#  - determine module versions
+#  - build minimal core (aka locker) of Scala, use the determined version number, publish to scala-integration
+#  - build those modules where a binary compatible version doesn't exist, publish to scala-integration
+#  - build Scala using the previously built core and modules, publish to scala-integration
+#  - run tests
+#  - for releases
+#    - stage Scala on sonatype
+#    - rebuild modules where no binary compatible version existed, stage them on sonatype
+#  - the Scala version is serialized to jenkins.properties, which is passed downstream to scala-release jobs
+
+
+# Specifying the Scala version:
+#  - To build a release (enables publishing to sonatype):
+#    - Specify SCALA_VER_BASE and optionally SCALA_VER_SUFFIX. The version is SCALA_VER=$SCALA_VER_BASE$SCALA_VER_SUFFIX.
+#    - After building a release, the jenkins job provides an updated versions.properties file as artifact.
+#      Put this file in the Scala repo and create a pull request, also update `baseVersion in Global` in build.sbt.
+#
+# - Otherwise, an integration build is performed:
+#    - version number is read from the build.sbt, extended with -[bin|pre]-$sha
+
+
+# Specifying module versions. We use release versions for modules.
+#  - Module versions are read from the versions.properties file.
+#  - Set <MODULE>_VER to override the default, e.g. XML_VER="1.0.4".
+#  - The git revision is set to <MODULE>_REF="v$<MODULE>_VER". Make sure the tag exists (you can't override <MODULE>_REF).
+
+
+# Modules are automatically built if necessary.
+#  - A module is built if it doesn't exist in the maven repository. Note that the lookup uses two versions:
+#    - The version of the module (see below how it's determined)
+#    - The binary version of of the SCALA_VER release that is being built
+#  - sbt computes the binary version when looking up / building modules (*). Examples:
+#    - 2.12.0-M1, 2.12.0-RC3: the full version is used
+#    - 2.12.0, 2.12.1-M1, 2.12.1-RC3, 2.12.1: the binary version 2.12 is used
+#
+#  - Example: assume that `scala-xml_2.11 % 1.0.3` and `scala-xml_2.12.0-M1 % 1.0.3` both exists
+#    - XML_VER=1.0.3 and SCALA_VER=2.11.7    => no rebuild (binary version remains 2.11)
+#    - XML_VER=1.0.3 and SCALA_VER=2.12.0-M2 => rebuild (new binary version 2.12.0-M2)
+#    - XML_VER=1.0.4 and SCALA_VER=2.11.7    => rebuild (new version for the module, not yet on maven)
+#      NOTE: this is not the recommended way of publishing a module. Instead, prefer to release `scala-xml_2.11 % 1.0.4`
+#            using the existing scala 2.11.6 compiler before releasing 2.11.7. Sometimes it's necessary though. One
+#            example was 2.11.1, which contained a fix in the backend (SerialVersionUID was ignored). All modules needed
+#            to be re-built using the 2.11.1 release, we could not use 2.11.0. We could also not release the modules
+#            after 2.11.1 was out, because that way the scala-library-all pom of 2.11.1 would depend on the old modules.
+#
+# (*) https://github.com/sbt/sbt/blob/v0.13.13/util/cross/src/main/input_sources/CrossVersionUtil.scala#L41
+
+
+# Binary incompatible changes in Modules: example with Scala 2.11 / 2.12 and scala-parser-combinators
+#  - The 1.0.x branch on scala-parser-combinators remains binary compatible with 1.0.0
+#  - Scala 2.11 will always use 1.0.x releases: we ship scala-parser-combinators with the distribution,
+#    so we cannot introduce incompatible changes in a minor release.
+#  - The master branch of scala-parser-combinators contains binary incompatible changes, versioned 1.1.x
+#  - Scala 2.12 will use 1.1.x releases
+#  - No changes to the build script required: just put the 1.1.x version number into versions.properties
+#
+# Note: It's still OK for a module to release a binary incompatible version to maven, for example
+# scala-parser-combinators_2.11 % 1.1.0. Users can depend on this in their sbt build. But for the
+# distribution (tar/zip archives, scala-library-all) we have to stay on the binary compatible version.
+
+
+# Credentials
+#  - `PRIVATE_REPO_PASS` password for `scala-ci` user on scala-ci.typesafe.com/artifactory
+#  - `SONA_USER` / `SONA_PASS` for sonatype
+
+
 publishPrivateTask=${publishPrivateTask-"publish"}
 publishSonatypeTaskCore=${publishSonatypeTaskCore-"publishSigned"}
 publishSonatypeTaskModules=${publishSonatypeTaskModules-"publishSigned"}

scripts/common

@@ -1,5 +1,4 @@
-# This is for forcibly stopping the job from a subshell (see test
-# below).
+# This is for forcibly stopping the job from a subshell (see test below).
 trap "exit 1" TERM
 export TOP_PID=$$
 set -e
@@ -24,7 +23,7 @@ mkdir -p "$LOGGINGDIR"
 rm -rf "$WORKSPACE/resolutionScratch_"
 mkdir -p "$WORKSPACE/resolutionScratch_"
 
-SBT_CMD=${sbtCmd-sbt}
+SBT_CMD=${SBT_CMD-sbt}
 SBT_CMD="$SBT_CMD -sbt-version 0.13.17"
 
 # repo to publish builds

scripts/jobs/integrate/bootstrap

@@ -1,77 +1,6 @@
 #!/bin/bash -e
 
-# Script Overview
-#  - determine scala version
-#  - determine module versions
-#  - build minimal core (aka locker) of Scala, use the determined version number, publish to scala-integration
-#  - build those modules where a binary compatible version doesn't exist, publish to scala-integration
-#  - build Scala using the previously built core and bootstrap modules, publish to scala-integration
-#  - for releases
-#    - stage Scala on sonatype
-#    - rebuild modules that needed a rebuild with this Scala build, and stage them on sonatype
-#  - the Scala version is serialized to jenkins.properties, which is passed downstream to scala-release jobs
-
-
-# Specifying the Scala version:
-#  - To build a release (this enables publishing to sonatype):
-#    - Specify SCALA_VER_BASE. You may also specify SCALA_VER_SUFFIX, the Scala version is SCALA_VER=$SCALA_VER_BASE$SCALA_VER_SUFFIX.
-#    - Note: After building a release, the jenkins job provides an updated versions.properties file as artifact.
-#      Put this file in the Scala repo and create a pull request, also update `baseVersion in Global` in build.sbt.
-#
-# - Otherwise, an integration build is performed:
-#    - version number is read from the build.sbt, extended with -[bin|pre]-$sha
-
-
-# Specifying module versions. We use release versions for modules.
-#  - Module versions are read from the versions.properties file.
-#  - Set <MODULE>_VER to override the default, e.g. XML_VER="1.0.4".
-#  - The git revision is set to <MODULE>_REF="v$<MODULE>_VER". Make sure the tag exists (you can't override <MODULE>_REF).
-
-
-# Modules are automatically built if necessary.
-#  - A module is built if it doesn't exist in the maven repository. Note that the lookup uses two versions:
-#    - The version of the module (see below how it's determined)
-#    - The binary version of of the SCALA_VER release that is being built
-#  - sbt computes the binary version when looking up / building modules (*). Examples:
-#    - 2.12.0-M1, 2.12.0-RC3: the full version is used
-#    - 2.12.0, 2.12.1-M1, 2.12.1-RC3, 2.12.1: the binary version 2.12 is used
-#
-#  - Example: assume that `scala-xml_2.11 % 1.0.3` and `scala-xml_2.12.0-M1 % 1.0.3` both exists
-#    - XML_VER=1.0.3 and SCALA_VER=2.11.7    => no rebuild (binary version remains 2.11)
-#    - XML_VER=1.0.3 and SCALA_VER=2.12.0-M2 => rebuild (new binary version 2.12.0-M2)
-#    - XML_VER=1.0.4 and SCALA_VER=2.11.7    => rebuild (new version for the module, not yet on maven)
-#      NOTE: this is not the recommended way of publishing a module. Instead, prefer to release `scala-xml_2.11 % 1.0.4`
-#            using the existing scala 2.11.6 compiler before releasing 2.11.7. Sometimes it's necessary though. One
-#            example was 2.11.1, which contained a fix in the backend (SerialVersionUID was ignored). All modules needed
-#            to be re-built using the 2.11.1 release, we could not use 2.11.0. We could also not release the modules
-#            after 2.11.1 was out, because that way the scala-library-all pom of 2.11.1 would depend on the old modules.
-#
-# (*) https://github.com/sbt/sbt/blob/v0.13.13/util/cross/src/main/input_sources/CrossVersionUtil.scala#L41
-
-
-# Binary incompatible changes in Modules: example with Scala 2.11 / 2.12 and scala-parser-combinators
-#  - The 1.0.x branch on scala-parser-combinators remains binary compatible with 1.0.0
-#  - Scala 2.11 will always use 1.0.x releases: we ship scala-parser-combinators with the distribution,
-#    so we cannot introduce incompatible changes in a minor release.
-#  - The master branch of scala-parser-combinators contains binary incompatible changes, versioned 1.1.x
-#  - Scala 2.12 will use 1.1.x releases
-#  - No changes to the build script required: just put the 1.1.x version number into versions.properties
-#
-# Note: It's still OK for a module to release a binary incompatible version to maven, for example
-# scala-parser-combinators_2.11 % 1.1.0. Users can depend on this in their sbt build. But for the
-# distribution (tar/zip archives, scala-library-all) we have to stay on the binary compatible version.
-
-
-# Requirements
-#  - SBT_CMD must point to sbt from sbt-extras
-#  - ~/.sonatype-curl, ~/.m2/settings.xml, ~/.credentials, ~/.credentials-sonatype, ~/.credentials-private-repo
-#    as defined by https://github.com/scala/scala-jenkins-infra/tree/master/templates/default
-#  - ~/.sbt/0.13/plugins/gpg.sbt with:
-#     addSbtPlugin("com.typesafe.sbt" % "sbt-pgp" % "0.8.1")
-
-# Note: private-repo used to be private-repo.typesafe.com. now we're running artifactory on scala-ci.typesafe.com/artifactory
-
-#### MAIN
+# See comment in bootstrap_fun
 
 source scripts/common