Nightly releases for 2.11.x #115
Conversation
Determine Scala version as:
1. $SCALA_VER_BASE$SCALA_VER_SUFFIX (if former variable is set)
2. By parsing the tag (if HEAD is tagged as v$base$suffix)
3. By parsing build.number for the base version, suffixing with -$sha-nightly
Serialize these versions to jenkins.properties, which are passed downstream to scala-release-2.11.x-dist.
This also removes the need to tag scala/scala-dist (not possible for nightlies, still encouraged for releases, but not a hard requirement).
Determine Module Versions
- When running in "versions.properties" mode (the default), derive tags from these versions and build, publishing only those modules that are not available yet.
- Otherwise, build HEAD for all modules, derive a -nightly version for them.
Bootstrap:
1. Build minimal core of Scala as this version (aka locker), publish to private-repo
2. Build modules required to bootstrap, publish to private-repo
3. Build Scala using the previously built core and bootstrap modules, publish to private-repo
This overwrites the minimal core on private-repo
Stage to sonatype (unless building a -nightly release):
1. Stage this Scala build on sonatype
2. Rebuild modules with this Scala build, and stage them on sonatype as well
This script can be run in multiple modes. It is design to work without any input,
so that it could be run in Travis CI. In that mode, it'll build a release when
the current HEAD of $SCALA_REF is tagged, and stage to sonatype. Otherwise,
it'll build a nightly.
Since the nightlies are intended to be a drop in replacement, all modules are built with the
full Scala version as their binary version, so that you can just set scalaVersion to the
nightly's sha-derived version and be good to go.
The other way to trigger a release is by setting the SCALA_VER_BASE env var.
By default, we build the versions of the modules as specified by versions.properties
(as specified in the $SCALA_REF commit). Set moduleVersioning to something random
to trigger building HEAD of each module, generating a fresh -$(git describe)-nightly version for each.
PS: set publishToSonatype to anything but "yes" to avoid publishing to sonatype
(publishing only done when $SCALA_REF's HEAD is tagged / SCALA_VER_BASE is set.)
|
Re-review by @retronym, please. |
|
(Not much has changed since our over-the-shoulder review, except that it now seems to work.) |
| @@ -1,4 +1,4 @@ | |||
| #!/bin/bash -ex | |||
There was a problem hiding this comment.
-x is very noisy, true, but it's often helpful to see invoked commands with all variables / arguments expanded.
There was a problem hiding this comment.
Yeah, it's a trade-off. I've tried to sprinkle echo statements to show the relevant variables. With -x, there's so much noise you don't even see the signal anymore.
|
@retronym, unless I hear from you first, I'll plan to merge this today. |
|
LGTM |
|
Yay! Now running https://scala-webapps.epfl.ch/jenkins/view/scala-release-2.11.x/job/scala-release-2.11.x every night. Doing a trial run: https://scala-webapps.epfl.ch/jenkins/view/scala-release-2.11.x/job/scala-release-2.11.x/78/console |
|
Will you also set this up for 2.12? |
|
No, I'll leave that up to @gkossakowski. |
|
I consider this my hand off as 2.11 infra dude to the 2.12 guy |
Refactor scala-release-2.11.x as follows:
Determine Scala version as:
Serialize these versions to jenkins.properties, which are passed downstream to scala-release-2.11.x-dist.
This also removes the need to tag scala/scala-dist (not possible for nightlies, still encouraged for releases, but not a hard requirement).
Determine Module Versions
Bootstrap:
This overwrites the minimal core on private-repo
Stage to sonatype (unless building a -nightly release):
This script can be run in multiple modes. It is design to work without any input,
so that it could be run in Travis CI. In that mode, it'll build a release when
the current HEAD of $SCALA_REF is tagged, and stage to sonatype. Otherwise,
it'll build a nightly.
Since the nightlies are intended to be a drop in replacement, all modules are built with the
full Scala version as their binary version, so that you can just set scalaVersion to the
nightly's sha-derived version and be good to go.
The other way to trigger a release is by setting the SCALA_VER_BASE env var.
By default, we build the versions of the modules as specified by versions.properties
(as specified in the $SCALA_REF commit). Set moduleVersioning to something random
to trigger building HEAD of each module, generating a fresh -$(git describe)-nightly version for each.
PS: set publishToSonatype to anything but "yes" to avoid publishing to sonatype
(publishing only done when $SCALA_REF's HEAD is tagged / SCALA_VER_BASE is set.)