Run sonatypeClose when a sonatype error is detected

[jvican]

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.

[jvican]

Do you have any thoughts on this @xerial?

[xerial]

I don't have much idea about this issue, but the default behavior of sbt-sonatype is trying to update the previously opened stagingRepositoryId (e.g., [orgxerial-1001]) unless you explicitly gives stagingRepositoryId, which is generated when publishSigned is performed to Sonatype repo. So if you have multiple sessions that performs publishSigned to the same sonatypeProfile, that can cause the issue.

An approach for making sure the correspondence between uploaded artifacts and stagingProfileIds would be explicitly specifying a profile name:
https://github.com/xerial/sbt-sonatype/blob/master/workflow.md#multi-session-workflow-example

Disclaimer: This workflow is from a contributor and I'm not actively using this feature.

[jvican]

Thank you for chiming in @xerial! The description of this issue is vague is because I haven't had time to isolate all the moving parts at play, but I've got indeed weird behaviors from sbt-sonatype's publishSigned trying to reuse an open repository that was opened by a failed release (in an independent CI run). As the failed release had not passed all the checks, the new release that tried to reuse it would fail too. Closing the repository immediately after publishSigned has failed would in theory avoid this issue.

The default behavior of sbt-sonatype is trying to update the previously opened stagingRepositoryId (e.g., [orgxerial-1001]) unless you explicitly gives stagingRepositoryId, which is generated when publishSigned is performed to Sonatype repo. So if you have multiple sessions that performs publishSigned to the same sonatypeProfile, that can cause the issue.

The only issue I see with this approach is that the argument that sonatypeOpen takes is the description, not the id (orgxerial-1001). sonatypeClose and sonatypePromote take the id. I'm not aware of a way to map from the description to the repository id. But don't worry, I believe I can live with it. Right now, sbt-release-early does ;$projectName/publishSigned;sonatypeRelease sequentially for every project.

The issue I report here seems unrelated to this sbt-sonatype step-by-step workflow.

[jvican]

This has happened several times in the CI. When a build has not yet run example-sonatype and is cancelled, the next CI run detects the previously opened repository and fails to release.

[info] [info] Nexus repository URL: https://oss.sonatype.org/service/local
[info] [info] sonatypeProfileName = org.bitbucket.jplantdev
[info] [info] Reading staging repository profiles...
[info] [error] Multiple repositories are found:
[info] [error] [orgbitbucketjplantdev-1204] status:open, profile:org.bitbucket.jplantdev(798f92f65f8ad6) description: Implicitly created (auto staging).
[info] [error] [orgbitbucketjplantdev-1205] status:open, profile:org.bitbucket.jplantdev(798f92f65f8ad6) description: Implicitly created (auto staging).
[info] [error] Specify one of the repository ids in the command line
[info] [error] java.lang.IllegalStateException: Found multiple staging repositories
[info] [error] 	at xerial.sbt.Sonatype$NexusRESTService.$anonfun$findTargetRepository$8(Sonatype.scala:479)
[info] [error] 	at scala.Option.getOrElse(Option.scala:121)
[info] [error] 	at xerial.sbt.Sonatype$NexusRESTService.findTargetRepository(Sonatype.scala:476)
[info] [error] 	at xerial.sbt.Sonatype$SonatypeCommand$.$anonfun$sonatypeRelease$1(Sonatype.scala:202)
[info] [error] 	at sbt.Command$.$anonfun$applyEffect$4(Command.scala:125)
[info] [error] 	at sbt.Command$.$anonfun$applyEffect$2(Command.scala:121)
[info] [error] 	at ch.epfl.scala.sbt.release.Helper.runCommand$1(ReleaseEarlyPlugin.scala:470)
[info] [error] 	at ch.epfl.scala.sbt.release.Helper.$anonfun$runCommandAndRemaining$1(ReleaseEarlyPlugin.scala:479)
[info] [error] 	at ch.epfl.scala.sbt.release.ReleaseEarly$Defaults$.$anonfun$sonatypeRelease$1(ReleaseEarlyPlugin.scala:251)
[info] [error] 	at ch.epfl.scala.sbt.release.ReleaseEarly$Defaults$.$anonfun$sonatypeRelease$1$adapted(ReleaseEarlyPlugin.scala:243)
[info] [error] 	at scala.Function1.$anonfun$compose$1(Function1.scala:44)
[info] [error] 	at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:42)
[info] [error] 	at sbt.std.Transform$$anon$4.work(System.scala:64)
[info] [error] 	at sbt.Execute.$anonfun$submit$2(Execute.scala:257)
[info] [error] 	at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:16)
[info] [error] 	at sbt.Execute.work(Execute.scala:266)
[info] [error] 	at sbt.Execute.$anonfun$submit$1(Execute.scala:257)
[info] [error] 	at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:167)
[info] [error] 	at sbt.CompletionService$$anon$2.call(CompletionService.scala:32)
[info] [error] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[info] [error] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[info] [error] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[info] [error] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[info] [error] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[info] [error] 	at java.lang.Thread.run(Thread.java:745)
[info] [error] (p2/*:releaseEarlyPublish) java.lang.IllegalStateException: Found multiple staging repositories
[info] [error] Total time: 38 s, completed Oct 16, 2017 10:36:23 AM
[error] x sbt-release-early / example-sonatype 
[error] Cause of test exception: {line 14} Command failed: p2/releaseEarly failed

I think that the best behaviour here would be to reuse the most recently opened repository instead of filing because sonatypeRelease is not done for a concrete repo ID.