Add support for dropping repository

[markwoon]

It would be nice if the plugin could also automatically drop the repo after successful promotion.

[szpak]

I thought that Nexus does it for you. Nevertheless I have never verified that.

Btw, do you need to release a different project using the same staging profile just after the first one? Or there is some other issue that you need it?

[markwoon]

Huh, so it does. I guess it just took way longer than I expected.

[szpak]

I'm reopening it as I found dropping repository useful in CD pipelines. In addition there is even PR #13 that I plan to work on.

[kylerjensen]

Do we have an ETA on this enhancement? I have encountered scenarios in which using it would be very helpful and would alleviate some headaches.

[szpak]

I need it in my CDeliveryBoy, so most likely it will be implemented. However, I have also other things, some duplication would need to be removed by the way and I started a migration to OkHttp some time ago, so I cannot promised any dates :(.

[szpak]

Btw @Kjens93, why do you need it so much?

[chinkong83]

hi @szpak , we also need this enhancement, thanks.

[szpak]

@chinkong83 Would enhancement proposed in #29 be sufficient for you? If not, could you write what do you need drop repository for?

[chinkong83]

Hi, @szpak
I am not sure #29 mentioned for what, but I think PR #13 meet my requirement. I see PR #13 say we need wait for 10min to drop after release to maven central, this resolve my problem but not enough, because we adopt travis as our CD pipeline, maybe 2 or above merge occur in very close, so we still need it, thanks

[szpak]

In #13 the requester had a problem with configuration and after my changes the dropRepositories task was not needed anymore. After promotion the artifacts should be dropped automatically with the similar delay that a regular drop operation. Therefore I wonder what is your exact use case.

[chinkong83]

ok, but how long of delay time? 10min?

[szpak]

It should be done "immediately" after promotion (Nexus itself should call drop internally). Do you have very large artifacts there? What was the shortest time you've got that error?

[chinkong83]

oh, strange.... Artifact not drop immediately after plugin promote push it, I try twice but always need to drop manually, my artifact file size about 60KB, totally about 30 jar file(include source and javadoc)

[szpak]

Strange. Is it an open source project available on GitHub?

[chinkong83]

@szpak this is our git repo: https://github.com/yahoo/parsec-libraries

[szpak]

I took a look at your builds.

The following case:

Execution failed for task ':closeRepository'.
> Wrong number of received repositories in state 'open'. Expected 1, received 2

usually occurs when the previous release try failed. It is required to drop trashy repository by hand via UI (and here #29 would be useful). There was a proposal to close all repositories, but it can be dangerous and I will try to implement that rather with #29.

Another group of problems is:

Execution failed for task ':promoteRepository'.
> Unexpected state of reveived repository. Received open, expected closed

It usually shouldn't happen, however, I think I have seen it before somewhere and reported #21. It may be related to the fact that you have multiple artifacts and it takes more time on the Nexus side).

Could you enable --info and paste the output (a retry mechanism wasn't used in that case for some reason)?

[chinkong83]

Thanks @szpak

I paste console full log to gist, please take a look:
https://gist.github.com/chinkong83/972eb9b56039851ea103177e6bb4fb07

And I still face the issue: Artifacts not drop after promote it, below is my screenshot:

Could you please check or take a look? thanks

[chinkong83]

Oh, I see staging repositories already drop comyahooparsec-1011, but seems it still keep a period of time before drop.

[szpak]

In the log I see that retry mechanism behaved properly in closeRepository, so it should also in promoteRepository. You can increase numberOfRetries to 20 or so (the default 7 seconds can be too short for multiple subprojects and it will be changed in the future version - #12). Anyway I need to improve logging without info to give an user a hint (created #34).

What was the time needed to make it closed? 5 minutes? 10? 1 hour? I propose you to reach the Sonatype guys via the mailing list: ossrh-users AT glists.sonatype.com and ask about that giving them that particular case (with a staging repository name).

I suspect that time can be needed to do release stuff and just after that a drop operation is performed. Therefore, a try to close the repository which is being promoted would fail (at best). However, I may be wrong and if for unknown reason a drop is not called just after a release operation is performed successfully it may be a good to add an extra drop after the release/promote (nevertheless, it would be much better to have it implemented on the Nexus side if in fact not available right now).

[chinkong83]

ok, thanks @szpak 👍

[szpak]

@chinkong83 Can you share a ticket in Sonatype Jira you created or a thread on the mailing list? I would like to follow that discussion (about delay between releasing and dropping).

[graemerocher]

Hi @szpak

We have a similar problem when publishing Grails using this plugin. What happens is we have multi-project build where two of the subprojects use the packaging "pom" instead of the default. These two end up in a separate staging repository and then we get the dreaded.

Execution failed for task ':closeRepository'.
> Wrong number of received repositories in state 'open'. Expected 1, received 2

See https://travis-ci.org/grails/grails-core/builds/193426489#L2361

Is there any reason why these two projects end up in a separate staging repo? Or any other workarounds for this issue?

[szpak]

@graemerocher It seems to be justified to have two repositories in your case. In travis-build.sh you:

• upload the artifacts
• the new repository is implicitly created
• close & promote the first repository
• upload another artifacts
• the 2nd repository is implicitly created (the 1st is already closed or in your case is rather being closed)
• close & promote the 2nd repository - there is the issue with the first repository not being closed already

Two ideas to consider:

1. You seem to upload bigger number of artifacts. Please add --info/-i to your closeAndPromoteRepository tasks execution (in the current configuration) which probably gives a result that timeout is too short. Then increase it with numberOfRetries and delayBetweenRetriesInMillis configuration parameters - it's better than sleep 30 (or more in your case) as it asks proactively e.g. every 5 or 10 seconds and finishes as soon as just one repo is available.
2. Do you need two separate 2 upload operations with closeAndPromote? 2 upload commands should end up in the same staging repository. Then you could just close and promote it (with 2 groups of artifacts).
   2b. Btw, I assume that integrationTest does not depends on artifacts available in The Central Repository (aka Maven Central) as it can takes up to several minutes to propagate.

[graemerocher]

@szpak Thanks for the feedback.

1. I will try this thanks.

2. We publish POM-only dependencies that use a different upload setup to the rest of the project, even if those are not published in separate steps they still end up in 2 different staging repositories. I'm not sure of a way around that since Gradle doesn't seem to natively allow publishing just POMs (so we use the Maven Ant tooling via Gradle)

[szpak]

@graemerocher @chinkong83 You can upgrade to 0.8.0. I changed the used REST API methods to have support for "autoDropAfterRelease" (#37). The released repository should be gone when Gradle task is finished.

[graemerocher]

@szpak great news, thanks!

[szpak]

Closing as the original request:

It would be nice if the plugin could also automatically drop the repo after successful promotion.

is implemented starting with version 0.9.0.

[szpak]

Please create a new issues if you have a good use case to be able to call dropRepository from Gradle on demand.