See #34 :
With version 2.1.1+4-9d76569a and sbt +releaseEarly I get:

java.lang.RuntimeException: Missing bintray credentials. Either create a credentials file with the bintrayChangeCredentials task, set the BINTRAY_USER and BINTRAY_PASS environment variables or pass bintray.user and bintray.pass properties to sbt.

even though my build.sbt specifies to publish using sonatype.

The full travis log is also available.

PR #37 provides a potential mitigation.

It would be great, if sbt-release would detect if it is run on a previously released version. This happens in CI, when a build is re-started after one successful release has been made.

It is often the case that when a repository fails to close or promote, the repository is still open. Next time sbt-sonatype runs a release, two things can happen:

• It will not create a new repository and will try to update the previous one, or
• It will open a new project and then sonatypeRelease will later on fail.

It is not obvious to identify that this is happening and it can be frustrating. As a result, for the sanity of the users, sbt-release-early should run sonatypeDrop after a repository is open and fails to be published.

this came up on scala/center Gitter (https://gitter.im/scala/center?at=5e42254d19597421f3bfe517)

before archiving, I'd suggest linking to sbt-ci-release from the readme

As pointed out by @laughedelic, this may be useful info to put in the wiki.

I think it will lay out more arguments to prefer this plugin over sbt-release. It will, of course, try to do so in an impartial way.

On this wiki page there is a link for windows users and it leads to "Page Not Found". Would be great to fix that.

I have an sbt build, which contains a root project, which aggregates many other projects. I configured all those projects, including the root project, for publishing on sonatype.

When I run the shell command sbt releaseEarly, the task releaseEarly is executed on all those projects because of aggregation. For each project, the task releaseEarly internally execute the command ;publishSigned;sonatypeRelease due to https://github.com/scalacenter/sbt-release-early/blob/9e50b77073120fac3bf37707d394e1db638bdb9f/src/main/scala/ch/epfl/scala/sbt/release/ReleaseEarlyPlugin.scala#L266

Unfortunately the command ;publishSigned;sonatypeRelease triggers aggregated projects, again. As a result, those aggregated projects are published twice, and sonatype reports an error message:

Artifact updating: Repository ='releases:Releases' does not allow updating artifact='/com/thoughtworks/sbt-best-practice/git_2.12_1.0/4.1.0+9-5a67fa32/git-4.1.0+9-5a67fa32-sources.jar'

The complete error log can be found at https://travis-ci.org/ThoughtWorksInc/sbt-best-practice/builds/505041539

Sonatype fails to publish projects that do not have the right metadata. The required metadata is explained here: https://blog.idrsolutions.com/2015/06/how-to-upload-your-java-artifact-to-maven-central/.

We do check some of these parameters (like the license), but we should provide smarter checks to ensure that users do define these keys in their builds! This is a nice improvement that can be implemented in the ReleaseEarlyPlugin class and tested via scripted (by getting a correct build that publishes and removing iteratively requirements that should be detected by the plugin).

Ideally, we would like to warn our users when they start up sbt so that they can quickly define these settings if they expect releasing to Sonatype to work.

Let's add releaseEarlyNoInstantReleases so that users can opt out of the releases on pull requests and master.

I have a Scala library that crosses multiple Scala versions, and I want to release early to Sonatype in Travis CI. Therefore I have the following configuration in .travis.yml:

scala:
  - 2.11.12
  - 2.12.8
  - 2.13.0-M4

Travis CI started three containers for the three different Scala versions. When sbt releaseEarly is executed, each container created a staging repository, and run sonatypeRelease command after artifacts are published to the staging repository.

Unfortunately, since there are three staging repositories in total, sonatypeRelease reports an error message as following:

[error] Multiple repositories are found:
[error] [comthoughtworksdsl-1037] status:open, profile:com.thoughtworks.dsl(bb5bd533a8c47) description: Implicitly created (auto staging).
[error] [comthoughtworksdsl-1038] status:open, profile:com.thoughtworks.dsl(bb5bd533a8c47) description: Implicitly created (auto staging).
[error] [comthoughtworksdsl-1039] status:open, profile:com.thoughtworks.dsl(bb5bd533a8c47) description: Implicitly created (auto staging).

The full CI log can be found at https://travis-ci.org/ThoughtWorksInc/Dsl.scala/builds/506086649

This is a feature request so that those users that must use private repositories can use them instead of bintray or sonatype.

I added addSbtPlugin("ch.epfl.scala" % "sbt-release-early" % "1.0.4") to project/plugins.sbt, however sbt (0.13.15) doesn't find the artifact.

It's looking for:

https://repo1.maven.org/maven2/ch/epfl/scala/sbt-release-early_2.10_0.13/1.0.4/sbt-release-early-1.0.4.pom

while there only exists:

https://repo1.maven.org/maven2/ch/epfl/scala/sbt-release-early/1.0.4/sbt-release-early-1.0.4.pom

This seems a rather basic thing to use the plugin, am I missing some sbt setting?

As reported by @kwark in the Gitter channel.

The new version adds support for bintray environment variables.

The plugin has been built with this functionality in mind and is CI independent.

This only requires adding docs to the README and maybe add a few lines of code to make Travis support more intuitive / out-of-the-box.

jFrog is sunsetting Bintray https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

So it's probably time to shift people to using Sonatype.

There are files in a repository, like docs, that should not affect the compilation of the project and therefore publish a new artifact (the artifact will be the same as the one previously released).

I would like sbt-release-early to allow me to define the whitelisted files in my build in the following way:

releaseEarlyWhitelistedFiles in Global := List("README.md", "CONTRIBUTING.md", ...)

When I commit this setting implementation, the releaseEarly would not trigger the publish task if only those files have been modified. If there's a change in any other file, it will publish an artifact as expected.

The implementation of this feature cannot assume that the previous commit has been released, and therefore we need to get the modified files since the last published commit (contrary to the last commit, i.e. HEAD~1).

Using sbt-release-early with sbt 1.3.0 and Sonatype creates one staging profile per artifact instead of propagating them to the same profile.
Here is an example failing with 1.3.0 and proof that things work with 1.2.8.
Here is the relevant section of the build log:

[info] Main Scala API documentation successful.
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1-javadoc.jar
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1.jar
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1-sources.jar
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1-javadoc.jar.asc
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1-sources.jar.asc
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1.pom.asc
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1.jar.asc
[info] 	published templating_2.11 to https://oss.sonatype.org/service/local/staging/deploy/maven2/org/combinators/templating_2.11/1.0.0+10-2c2a11f1/templating_2.11-1.0.0+10-2c2a11f1.pom
[success] Total time: 103 s (01:43), completed Sep 20, 2019, 6:20:23 PM
[info] Nexus repository URL: https://oss.sonatype.org/service/local
[info] sonatypeProfileName = org.combinators
[info] Reading staging repository profiles...
[error] Multiple repositories are found:
[error] [orgcombinators-1098] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1099] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1100] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1101] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1102] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1103] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1104] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] [orgcombinators-1105] status:open, profile:org.combinators(1003943c9bbbfd) description: Implicitly created (auto staging).
[error] Specify one of the repository ids in the command line
[error] java.lang.IllegalStateException: Found multiple staging repositories
[error] 	at xerial.sbt.Sonatype$NexusRESTService.$anonfun$findTargetRepository$8(Sonatype.scala:479)
[error] 	at scala.Option.getOrElse(Option.scala:138)
[error] 	at xerial.sbt.Sonatype$NexusRESTService.findTargetRepository(Sonatype.scala:476)
[error] 	at xerial.sbt.Sonatype$SonatypeCommand$.$anonfun$sonatypeRelease$1(Sonatype.scala:202)
[error] 	at sbt.Command$.$anonfun$applyEffect$4(Command.scala:149)
[error] 	at sbt.Command$.$anonfun$applyEffect$2(Command.scala:144)
[error] 	at ch.epfl.scala.sbt.release.Helper.runCommand$1(ReleaseEarlyPlugin.scala:524)
[error] 	at ch.epfl.scala.sbt.release.Helper.$anonfun$runCommandAndRemaining$1(ReleaseEarlyPlugin.scala:533)
[error] 	at ch.epfl.scala.sbt.release.ReleaseEarly$Defaults$.$anonfun$sonatypeRelease$1(ReleaseEarlyPlugin.scala:267)
[error] 	at ch.epfl.scala.sbt.release.ReleaseEarly$Defaults$.$anonfun$sonatypeRelease$1$adapted(ReleaseEarlyPlugin.scala:259)
[error] 	at scala.Function1.$anonfun$compose$1(Function1.scala:49)
[error] 	at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:62)
[error] 	at sbt.std.Transform$$anon$4.work(Transform.scala:67)
[error] 	at sbt.Execute.$anonfun$submit$2(Execute.scala:280)
[error] 	at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:19)
[error] 	at sbt.Execute.work(Execute.scala:289)
[error] 	at sbt.Execute.$anonfun$submit$1(Execute.scala:280)
[error] 	at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:178)
[error] 	at sbt.CompletionService$$anon$2.call(CompletionService.scala:37)
[error] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error] 	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[error] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[error] 	at java.base/java.lang.Thread.run(Thread.java:834)
[error] (releaseEarlyPublish) java.lang.IllegalStateException: Found multiple staging repositories

In the failing example, you can see that there are 8 artifacts and 8 options for staging repositories.

I'd guess that something is running in parallel in 1.3.0, which was sequentially previously. I did not test against 1.3.2 (yet), because its changelog seemed to be unrelated.

This is unrelated to #30 because there is only one project. It is also different from #32, because there are 3 Scala versions in my project and 8 (number of things to upload) staging repositories.

I've seen that certain releases fail to succeed because they lack javadoc and sources. I've assumed that Central forces artifacts to provide javadoc and sources, but I still need to double check this.

With the previous assumption, sbt-release-early should fail if publishArtifact in doc and sources is false and tell users that they should enable those artifacts if they want to sync to Central.

The page that explains how to release with Bintray is less specific than the one to release with Sonatype.

Concretely, it misses the following sections:

• You don't have a Bintray account.
• You have a Bintray account.
• Clear "Meta info".

The current "Releasing to Maven Central" section should be a sub-section of "You have a bintray account".

This is a feature request so that those users that dislike bintray can publish to sonatype instead.

@tpolecat has shown interest in releasing non-final releases to Sonatype instead of Bintray. Currently, we support releasing to Sonatype only final releases. https://gitter.im/scalacenter/sbt-release-early?at=594ae5bfcf9c13503cae3cca

Releasing to Sonatype would not require to define sbt-bintray settings and would bring in sbt-sonatype as a dependency. We need to reconcile both dependencies and avoid any clash that can happen from overriding settings/tasks.