No such file or directory after upgrading to 4.0.0 #99
Comments
Use an earlier version as version 4.x is breaking the builds. Ref: ajoberstar/gradle-git-publish#99
4.x breaks publishing See ajoberstar/gradle-git-publish#99
|
Sorry for the delay. I appreciate the sample project and the links to those related issues. It seems like if the Will look through Gradle's docs/code/issues to see how we're supposed to handle this. gradle/gradle#9041 is an indication of where they're headed (not allowing two tasks to use the same directory). And I get it, in general, but there are use cases like this that aren't feasible to handle if they're going to fiddle with the directories all the time. Needs to be some way to say "I've got this, just leave my files alone". |
Gradle fairly aggressively tries to cleanup stale output files, with the goal of reliable build caching to avoid the need to run "./gradlew clean". However, this is problematic for tasks that have overlapping output directories, as it makes it difficult for Gradle to track what's stale. In a prior version we added the @UntrackedTask annotation to all of the publish tasks to avoid Gradle's state tracking. However, we use the built-in Gradle Copy task for one part of our chain, which does not have that annotation. In cases where the .gradle directory was not present, we would see the repository directory get deleted after the gitPublishCopy task ran, because Gradle thought it was stale. In other cases it seemed to be fine. While I don't understand the details of how Gradle makes those stale/fresh decisions, particularly in the absence of the .gradle directory, it seems the key is using the runtime method equivalent of the @UntrackedTask annotation (Task.doNotTrackState) to tell Gradle not to do its state tracking for this one task. We could still have issues in the future, but this seems to get us over the immediate hurdle. Fixes #99
|
I think I've got a solution, will be releasing it as 4.1.1. |
Gradle fairly aggressively tries to cleanup stale output files, with the goal of reliable build caching to avoid the need to run "./gradlew clean". However, this is problematic for tasks that have overlapping output directories, as it makes it difficult for Gradle to track what's stale. In a prior version we added the @UntrackedTask annotation to all of the publish tasks to avoid Gradle's state tracking. However, we use the built-in Gradle Copy task for one part of our chain, which does not have that annotation. In cases where the .gradle directory was not present, we would see the repository directory get deleted after the gitPublishCopy task ran, because Gradle thought it was stale. In other cases it seemed to be fine. While I don't understand the details of how Gradle makes those stale/fresh decisions, particularly in the absence of the .gradle directory, it seems the key is using the runtime method equivalent of the @UntrackedTask annotation (Task.doNotTrackState) to tell Gradle not to do its state tracking for this one task. We could still have issues in the future, but this seems to get us over the immediate hurdle. Fixes #99
|
Thanks for the fix! |
Summary
When running the
gitPublishCommitcommand with version 4.0.0 or above the build fails withException caught during execution of add command.caused byNo such file or directory. This was working before in the 3.0.1 version.Build file
Example build file can be found in this project: https://github.com/arhohuttunen/awstestkit/blob/main/documentation/build.gradle.kts
There is currently no smaller project to demonstrate the issue but could be provided to reproduce the issue if needed.
Output
Looks similar to #65 and #35
The text was updated successfully, but these errors were encountered: