Skip to content

Follow-up to build changes #406

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Follow-up to build changes #406

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 2 additions & 4 deletions build.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,9 +68,7 @@ if [[ "$TRAVIS_TAG" =~ $tagPat ]]; then
exit 0
fi
else
if isTagScalaReleaseJob; then
setTagScalaVersion='set every scalaVersion := "'$tagScalaVer'"'
else
if ! isTagScalaReleaseJob; then
echo "The releases for Scala $tagScalaVer are built by other jobs in the travis job matrix"
exit 0
fi
Expand All @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems worth keeping around for publishing Dotty RC artifacts.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, so he's suggesting running sonatypeDrop instead of aborting the script with exit 0?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, I opened sbt/sbt-ci-release#102 to see if Olaf has an “official” position on this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea! Thanks, Seth.

sbt clean $projectPrefix/test $projectPrefix/publishLocal $releaseTask