Giters

xerial / sbt-sonatype

A sbt plugin for publishing Scala/Java projects to the Maven central.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Determining Sonatype host on a per-user level, rather than build/project-level?

rtyley opened this issue · comments

commented

Further to #215 & #248 :

Whether publishing action should be performed to oss.sonatype.org or s01.oss.sonatype.org seems to be more like a user-level thing than a build/project-level thing. In my organisation we've got several developers, some of whom are on the older oss.sonatype.org infrastructure, and some who are on the new s01.oss.sonatype.org service - consequently, we don't want to commit the new sonatypeCredentialHost into our project repository, as it'll inevitably be incorrect for at least some of our users until they're all migrated over onto s01.oss.sonatype.org, which we're just evaluating for now.

Possible solutions

Using the host defined in the credentials setting

Deriving the correct Sonatype host from the plain-old credentials setting could work? My current ~/.sbt/1.0/sonatype.sbt file looks like this:

credentials += Credentials("Sonatype Nexus Repository Manager",
        "s01.oss.sonatype.org",
        "mySonatypeUsername",
        "mySonatypePassword")

...the second parameter has to be s01.oss.sonatype.org - if it's left at oss.sonatype.org, then this error occurs:

[MISSING_CREDENTIAL] No credential is found for s01.oss.sonatype.org. Prepare ~/.sbt/(sbt_version)/sonatype.sbt file.
	at xerial.sbt.sonatype.SonatypeClient.$anonfun$directCredentials$1(SonatypeClient.scala:45)
	at scala.Option.getOrElse(Option.scala:189)
	at xerial.sbt.sonatype.SonatypeClient.directCredentials$lzycompute(SonatypeClient.scala:43)

...as it already has to be correct, couldn't the host be read from there rather than the new sonatypeCredentialHost setting?

Workaround

For now, we can kind of achieve the not-committed-to-the-project-repo arrangement by adding the new setting to our user-home level file (~/.sbt/1.0/sonatype.sbt):

$ grep sonatypeCredentialHost ~/.sbt/1.0/sonatype.sbt
ThisBuild / sonatypeCredentialHost := "s01.oss.sonatype.org"

...unfortunately, as sonatypeCredentialHost is a setting provided by the sbt-sonatype plugin, this also means adding sbt-sonatype as a user-level plugin (when we'd rather that was committed to the project repo):

$ grep sonatype ~/.sbt/1.0/plugins/plugins.sbt
addSbtPlugin("org.xerial.sbt" % "sbt-sonatype" % "3.9.10")
commented

Thanks for the information. I didn't know new users also need to use s01.oss.sonatype.org for the authentication for accessing old projects. I'd like to confirm whether we can use s01.oss.sonatype.org to update old projects hosted at oss.sonatype.org. If the answer is yes, we should extract sonatypeCredentialHost from the user-provided Credential.

commented

I think I was wrong about choice of Sonatype host being a user-level thing than a build/project-level thing. It actually seems to be determined by the project's groupId, which I realised after asking Sonatype if they could migrate my work's groupId for me without also requiring all other developers at my work having to update their credentials at the same time - it turns out they can't, the Sonatype host used for a groupId has to be migrated for everyone at once or not at all.

At the moment I'm in the state where I publish to the new sonatype host s01.oss.sonatype.org for my personal groupId (eg this release), and the old sonatype host oss.sonatype.org for my work groupId (example).

I'm closing this issue as I was entirely wrong, but I guess there might still be some improvements that could be made - maybe querying both Sonatype hosts to see where the profile/groupId is recognised (sbt-sonatype is currently raising a MISSING_PROFILE error if you use the wrong Sonatype host?) and then use that one?