search

gradle-nexus / publish-plugin

Gradle plugin for publishing to Nexus repositories
Apache License 2.0
399 stars 29 forks source link

Explain and document the staging repository isolation #63

Closed mockitoguy closed 3 years ago

mockitoguy commented 3 years ago

Nice plugin! (again!)

How does this plugin handle parallel publications from different GitHub projects that share the same group id, and publish to the same nexus repo (nexus oss)? Let's call it "staging repository isolation" use case.

Let's make it a little more concrete. In Mockito we have "org.mockito:mockito-kotlin" and "org.mockito:mockito-scala". Those are separate GH projects with independent release cycles. We have a strong preference to keep the same group "org.mockito" (branding, compatibility). What happens if both of those projects use the publish-plugin, and trigger release at the same time, to the same nexus repo (OSS sonatype)? Specifically, will the project use separate staging repositories?

Ask: please document this use case :) ping @szpak

szpak commented 3 years ago

In general, every publishing explicitly creates a new staging repository. If you call publishToSonatype closeAndReleaseSonatypeStagingRepository together, the closing and release operations will know which repository should be closed. It should cover the majority of cases.

For people with more complex release process (such as formal acceptation of the artifacts released to a (already closed) staging repository), the is a discussion about possible implementation in #19.

Having that knowledge, maybe you would like to provide a PR with improved explanation in README (in the way is - in your opinion - would be suitable for the users)? ;-)

P.S. There is one important Nexus-related (not just Gradle-related) issue which you need to be aware of. Having everything in the same group (package) imposes that user with permission to publishing to that group (in fact to the same staging profile using the Nexus domain) would be allowed to publish to every project in that group (so misconfigured mockito-kotlin could appear as mockito-core). Nevertheless, with a separate user used on a CI server with no user reversible access token, the risk of "mistake" is lower.