search

Codearte / gradle-nexus-staging-plugin

Automatize releasing Gradle projects to Maven Central.
Apache License 2.0
172 stars 26 forks source link

closeRepository and releaseRepository shouldn't be executed in parallel #70

Closed szpak closed 4 years ago

szpak commented 6 years ago

As reported in #69 it seems that closeRepository and releaseRepository can be executed in parallel even for the same project. There should be a strict dependency defined.

larsgrefer commented 4 years ago

I also had an issue where an publish task failed to upload its artifact, because the closeRepository task already closed the repository, so there should also be an explicit order dependency to all publish tasks

szpak commented 4 years ago

Which version do you use? I was investigating it a year ago and it seemed to be an inconsistency how Gradle handle that case with depending failed tasks. If the problem you are facing is still valid in the recent Gradle version (6.x) I will report it as a bug to Gradle.

larsgrefer commented 4 years ago

Here is a build scan of a failed build: https://scans.gradle.com/s/4ysuqst474wua

It was Gradle 5.6.4, because this plugin doesn't work with Gradle 6 (see #141)

szpak commented 4 years ago

Thanks, I will try to bring back the minimal case I had a year ago to report it.

Regarding Gradle 6, I would like to have the change properly tested first.

szpak commented 4 years ago

@larsgrefer FYI, I came back to that case and I realized that your problem is not the same as the original one. The root problem was to (try to) execute releaseRepository even if closeRepository fails - #69.

In your case closeRepository is executed before some of the publish* tasks, which is traced in #157 and in the meantime can be worked around with mustRunAfter.

szpak commented 4 years ago

@pavolloffay It's been long time, but I finally took a look at the original problem reported initially in #69, but diverged later on to a problem with Travis and multiple staging repositories. I planned to report an issue in Gradle, but it turned out that I'm not sure if it is a bug there. This comment is just an update, but you might be interested as it still may affect your project :).

The problem occurs even in the sequential execution having 4 (simple) tasks orchestrated the following way:

t2.mustRunAfter t1
fin.dependsOn t1
fin.dependsOn t2
mytask.finalizedBy fin

When mytask (in your case (then) uploadArchives) is executed it forces fin (closeAndReleaseRepository) to be executed which in turns need t1 (closeRepository) and t2 (releaseRepository). The not intuitive is that t2 executes even if t1 fails. However, finalizers are also used to clean up the stuff, so some might want to keep it that way.

In your case you could:

  1. Resign from using finalizedBy. In fact, you could probably just use the releaseArtifacts task having it dependsOn on closeAndReleaseRepository and publish (all of them). In addition as mentioned in #157 it would be required to make the closeRepository and releaseRepository tasks mustRunAfter all the publish tasks in your project.

Update. Looking at the current source code I realized that use started to use some releasing plugin. In that case it may be enough to wire them to afterReleaseBuild depending on your needs (keeping in mind that they have to be executed after all publish tasks).

  1. Add custom checking in t2 to be executed only if t1 finished successfully.

Probably it is not worth your energy.

Btw, finalizedBy has also some other limitations, e.g. https://github.com/gradle/gradle/issues/3691.

Let me know if you need any more support on your case.