No such file or directory after upgrading to Gradle 4.2 #35
Comments
|
Just checked my compatibility suite and it passes against 4.2. Not to say those are exhaustive, so could be missing something. That exception though seems more tied to general JGit behavior. So it could be something just in the general config/environment of the grgit/jgit. Did you make any other changes to your Gradle build when moving to 4.2? |
|
We did some changes like updating to latest versions of other plugins -- but after downgrading to Gradle 4.1 the gradle-git-publish, grgit/jgit issue disappeared. |
|
Interesting. I spent a few minutes trying to recreate this with the JUnit5 repo, but was having trouble (and the build is quite time consuming). If you can reproduce this in a smaller sample, that would be helpful. |
|
I was not able to create a smaller example that shows the issue. ): We still do observe a working Gradle 4.1 + Jenkins setup. When we re-upgrade to Gradle 4.2.x (or later) and the issue raises again, I'll come back to you. |
|
Sounds good. |
|
Same issue here. Any progress on this? Thanks. |
|
No progress yet. If you have something reproducible that I can test with that would help. |
|
With JDK 9.0.1 released, we need to upgrade to Gradle 4.3 ( |
|
The issue is still "alive". See https://junit.ci.cloudbees.com/blue/organizations/jenkins/JUnit5/detail/master/23/pipeline/ for a |
|
Mh... Run 22 failed: Run 23 with Race condition? |
|
The stack trace indicates we're failing creating a temp file inside of the object directory. Not sure why that would be missing at that point in the build. I'll try to run your project again tomorrow and see if I can reproduce it locally. |
|
Thanks in advance. I'll keep the Btw. I found following warning in the full log of run 23: |
|
Run 24 now failed with |
|
So far I haven't gotten as far as your build does. On my desktop, it keeps crashing during the startup of gitPublishCopy trying to "delete stale outputs", which for some reason includes it trying to delete the repository. It specifically fails trying to delete one particular pack file. Not entirely sure it's related, but if Gradle's trying to delete the repository (and succeeds), that could result in a lack of an object directory when it gets to the add in gitPublishCommit. Will try backing this down to 4.1 and see if it still does the same for me. |
|
While that 4.1 runs, looking at Gradle source and it seems that stale outputs cleanup was introduced in 4.2. This might be a matter of some missing output declarations on my part in the tasks in this plugin. |
|
And yes, 4.1 worked locally for me. Not sure why your build got farther than mine (maybe some Windows vs Linux differences), but seems like they both might be related to the stale outputs cleanup. |
As of Gradle 4.2, when execution of a task begins, any "stale" outputs will be deleted. All files under build and any declared outputs are considered managed by Gradle. If other files happen to be in there, Gradle will delete them. The reset task did not declare any outputs, but created the build/gitPublish directory and cloned the repo in there. When the copy task rolls around, it sees some that cloned repo as stale files in its output directory, since the copy task didn't put them there. Since they are also under build, Gradle considers itself the owner and thinks it's safe to delete them. By declaring the repodir as an output, the intent is to prevent Gradle from considering those stale outputs. We still need to be careful not to make Gradle do up-to-date logic on the reset task, since that isn't really possible to declare with normal Gradle input options. This is intended to address #35. [1] https://docs.gradle.org/4.2/release-notes.html#safer-handling-of-stale-output-files
As of Gradle 4.2, when execution of a task begins, any "stale" outputs will be deleted. All files under build and any declared outputs are considered managed by Gradle. If other files happen to be in there, Gradle will delete them. The reset task did not declare any outputs, but created the build/gitPublish directory and cloned the repo in there. When the copy task rolls around, it sees some that cloned repo as stale files in its output directory, since the copy task didn't put them there. Since they are also under build, Gradle considers itself the owner and thinks it's safe to delete them. By declaring the repodir as an output, the intent is to prevent Gradle from considering those stale outputs. We still need to be careful not to make Gradle do up-to-date logic on the reset task, since that isn't really possible to declare with normal Gradle input options. This is intended to address #35. [1] https://docs.gradle.org/4.2/release-notes.html#safer-handling-of-stale-output-files
|
Pushing out a 0.3.2-rc.1, including what seems to be a fix for this. Haven't figured out if/how I can make a test for this in this repo, but it seems to resolve the stale outputs issue in the junit5 project. |
|
I'll try it right away... |
|
Run 32 is green on the first attempt: A comment from @wolfs or sombody else from Gradle would be welcome regarding this issue. |
|
Run 33 does not longer use Thanks Andrew for fixing this! |
|
@sormuras I commented on #39. The problem you are experiencing is due to better stale output file handling as already correctly analyzed by @ajoberstar. There are problems when tasks which declare outputs write to the same files/directories as tasks which do not. So either all the tasks writing to one directory should declare their input and outputs correctly or none of the tasks should declare any inputs or outputs. |
|
Thanks for chiming in @wolfs -- much appreciated. |
As of Gradle 4.2 [1], when execution of a task begins, any "stale" outputs will be deleted. All files under build and any declared outputs are considered managed by Gradle. If other files happen to be in there, Gradle will delete them. The reset task did not declare any outputs, but created the build/gitPublish directory and cloned the repo in there. When the copy task rolls around, which is a built in task with declared inputs/outputs, it sees some that cloned repo as stale files in its output directory, since the copy task didn't put them there. Since they are also under build, Gradle considers itself the owner and thinks it's safe to delete them. Since the inputs/outputs of the tasks in this plugin both overlap and sometimes aren't clear files in / files out situations, it is easier for now to drop using them altogether. This commit drops the use of the Copy task, in favor of a ad-hoc task that uses project.copy. This was the only task that had any inputs/outputs declared before, so this issue should no longer be able to present. This fixes #35. [1] https://docs.gradle.org/4.2/release-notes.html#safer-handling-of-stale-output-files
As of Gradle 4.2 [1], when execution of a task begins, any "stale" outputs will be deleted. All files under build and any declared outputs are considered managed by Gradle. If other files happen to be in there, Gradle will delete them. The reset task did not declare any outputs, but created the build/gitPublish directory and cloned the repo in there. When the copy task rolls around, which is a built in task with declared inputs/outputs, it sees some that cloned repo as stale files in its output directory, since the copy task didn't put them there. Since they are also under build, Gradle considers itself the owner and thinks it's safe to delete them. Since the inputs/outputs of the tasks in this plugin both overlap and sometimes aren't clear files in / files out situations, it is easier for now to drop using them altogether. This commit drops the use of the Copy task, in favor of a ad-hoc task that uses project.copy. This was the only task that had any inputs/outputs declared before, so this issue should no longer be able to present. This fixes #35. [1] https://docs.gradle.org/4.2/release-notes.html#safer-handling-of-stale-output-files
|
Upgraded to 0.3.2-rc.2 via junit-team/junit5@460ac93 and it looks good to me: https://junit.ci.cloudbees.com/blue/organizations/jenkins/JUnit5/detail/master/35/pipeline |
|
Great! Thanks! |
|
Hi, see this issue back. I have the plugin in version It happens only when I remove |
|
@chali Just from the description, I could see this as potentially expected (though undesired) behavior. With just the If that doesn't work, can you open a new issue with some details of a working vs non-working config? Might be able to hunt down where the difference is. |
|
@ajoberstar thank you for quick follow up. The problem happens during a fresh clone and I verified that it happens even when I include |
I think this exception is related to
gradle-git-publishwhen running on Gradle 4.2 -- or am I mistaken?See log after the upgrade to Gradle 4.2 with complete stacktrace at https://junit.ci.cloudbees.com/blue/organizations/jenkins/JUnit5/detail/JUnit5/2230/pipeline
Or this is the latest one with more debug information:
https://junit.ci.cloudbees.com/blue/rest/organizations/jenkins/pipelines/JUnit5/runs/2260/log/?start=0
The text was updated successfully, but these errors were encountered: