Follow-up to build changes #406
Conversation
|
Maybe this was an artifact of trying to test the build script by running it locally? |
ashawley
force-pushed
the
build-followup
branch
from
9bead61
to
5a8a3ba
Compare
| @@ -86,4 +84,4 @@ export CI_SNAPSHOT_RELEASE="$projectPrefix/publish" | |||
| # for now, until we're confident in the new release scripts, just close the staging repo. | |||
| export CI_SONATYPE_RELEASE="; sonatypePrepare; sonatypeBundleUpload; sonatypeClose" | |||
|
|
|||
| sbt "$setTagScalaVersion" clean $projectPrefix/test $projectPrefix/publishLocal $releaseTask | |||
There was a problem hiding this comment.
I think this is wrong (in the current setup). If I create a tag v1.2.3#2.13.0-M3, this should override the scala version defined in TRAVIS_SCALA_VERSION, that's the core of the feature.
To simplify the scripts, I'd be fine dropping the tagScalaVer (the ability to re-release just by adding the scala version to the tag, like v1.2.3#2.13.0-M3) and everything related completely. This would mean that, if you want to re-release an existing scala-xml for a new Scala version (or a new Scala.js version), you take the commit of the corresponding scala-xml tag, change the .travis.yml to only include the new Scala (Scala.js) version(s) that you want to re-build for, and create a new tag for this commit.
Mabye this is the best way forward, given that binary incompatible Scala or Scala.js releases are not going to be frequent in the future. cc @SethTisue, what do you think?
There was a problem hiding this comment.
So the assumption with the feature, the script setting scalaVersion explicitly, is that you would just create the tag and you would publish artifacts without having to commit anything or change the build at all? Does that happen often? That has not been the case in my experience, but maybe I've been doing things wrong.
There was a problem hiding this comment.
you would just create the tag and you would publish artifacts without having to commit anything or change the build at all?
Yes, that is/was the idea. It worked for a few times, especially during milestone/RC cycles, where each release is binary incompatible, and they're relatively close to each other. But now that this situation is pretty far out, it's probably simpler to just remove the feature.
There was a problem hiding this comment.
It seems worth keeping around for publishing Dotty RC artifacts.
There was a problem hiding this comment.
Now that we're on sbt-ci-release, each target gets its own staging repo. (Before, we used to get an unpredictable number containing an unpredictable mix of files.) So one way to handle this is to just publish everything, then drop the unwanted staging repos. Throwing the idea out there.
There was a problem hiding this comment.
Oh, so he's suggesting running sonatypeDrop instead of aborting the script with exit 0?
There was a problem hiding this comment.
@ashawley I'm suggesting: leave the script alone, let all combinations publish, and then in the Sonatype web UI, manually choose which repos to drop or release.
Lukas's suggestion (of pushing a commit that omits the combinations we don't want) works fine too.
There was a problem hiding this comment.
Ok, sounds like you and Lukas are suggesting the same thing. I rely on Lightbend team for releases, so I defer to you. I'll work on ripping it out. I'll just need to keep the Java version checks.
There was a problem hiding this comment.
fwiw, I opened sbt/sbt-ci-release#102 to see if Olaf has an “official” position on this
There was a problem hiding this comment.
That's a good idea! Thanks, Seth.
|
Closed in favor of #417. |
This is from discussion in #387. Essentially, there's no need to set
scalaVersionwhen sbt-travisci is hinting it fromTRAVIS_SCALA_VERSIONenvironment variable.