Closed mkutz closed 1 month ago
Do you have a copy of the trace.log when 0.3 was released? The trace you posted shows that 0.3.1 was successfully released. The release
section clearly shows that both overwrite
and update
were set to true
.
Though it does not make sense to set both properties as overwrite
drops and creates the release while update
modifies a matching release. It should be enough to define overwrite
.
I do not, but the described behavior was the same for 0.3.1.
You can have a look at the build here. I agree that the release was kinda successful. It seems that it did all that it should, but the workflow fails anyway.
I see what the problem is. The jreleaserFullRelease
task is invoked multiple times. The first time is from the root and thus it's successful. The second time is from the bom project.
This is an error on your configuration. The JReleaser plugin is not design to be applied multiple times on several projects belonging to a multi-project setup.
The usual configuration structure is to apply the plugin to the root, or a secondary project that's in charge of publication/release.
There's nothing to be fixed on the JReleaser codebase. However, adding a note to https://jreleaser.org/guide/latest/tools/jreleaser-gradle.html regarding how and where to apply the project may be worth while.
Thanks so much for taking such a deep look, @aalmiray.
It was quite a journey to configure the whole thing in the project and to make it work with publishing. So those extra plugin declarations are just leftovers from desperate trying.
I removed the extra plugin declarations and now everything works just fine :)
Task List
Steps to Reproduce
./gradlew jreleaserConfig -Pversion=0.3 --git-root-search
(will succeed)./gradlew publish -Pversion=0.3
(will succeed)./gradlew jreleaserFullRelease -Pversion=0.3 --git-root-search --stacktrace
(will fail)Expected Behaviour
I'd expect the build not to throw an exception.
Actual Behaviour
As of now there is a release created by JReleaser and the artifacts are published as expected. However, the jreleaserFullRelease step throws an exception complaining, that the release already exists. It definitely didn't exists when the workflow started. I'd expect this not not happen.
Even though I configured
the thrown exception states otherwise:
Environment Information