Open jfrosch opened 5 years ago
Hello, thanks for sharing!
Since Gradle does not guarantee task ordering depending on what tasks are written, but instead guarantees they are executed in the order of their dependencies, I suspect that you'll want to add a link/ dependsOn
to ensure the order of tasks that you're looking for.
This is more an FYI than a bug report.
In my client's project, we execute the
releaseUpdateVersion
task provided by the ResearchGate gradle-release plugin before we execute thepublish
task from your plugin. (There's some history for doing it in this order that I won't bore you with.) ThereleaseUpdateVersion
task bumps theversion
number in gradle.properties so the next build uses that version number.It may be significant to this issue scenario that both tasks are executed in the same Gradle command; i.e.
gradlew releaseUpdateVersion publish
.In Gradle 3.5.1, this ordering worked fine. The published artifact had the
version
number initially read by Gradle from gradle.properties when Gradle command executed.After upgrading to Gradle 4.10.3, this same ordering no longer works and the
publish
task publishes an artifact using the newly updated version number.In reviewing Gradle debug output from the build job, it's not obvious what drove the changed behavior. I'm suspicious Gradle 4 is caching a mutable version number that the
releaseUpdateVersion
caused to be mutated, but I'm just not sure.Ours is likely an unorthodox scenario where the next version number is set before the publish is done, but I thought I'd mention it here in case someone else bumps into this.