-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplified TemporaryDirectoryAllocator.dispose #198
Simplified TemporaryDirectoryAllocator.dispose #198
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me - but I would generally not require a run of the gc
as stated
src/main/java/org/jvnet/hudson/test/TemporaryDirectoryAllocator.java
Outdated
Show resolved
Hide resolved
#166 does not guarantee it will detect a bug. But if it detects something, you may be sure that there is a bug in code. I want to say that "able to detect bugs unreliably" is better than "unable to detect bugs". The point of #166 is not to delete directory. Nobody cares if it is deleted or not, actually! The point is to catch buggy code that forgot to close file descriptors after finishing. jenkinsci/git-plugin#798, jenkinsci/subversion-plugin#240 and jenkinsci/workflow-support-plugin#99 were all actual bugs in production code of plugins, discovered thanks to #166. |
If you need some help figuring out what exact code is guilty in failed tests in jenkinsci/jenkins#4447 - I can definitely do that. |
…to TemporaryDirectoryAllocator.dispose
…to TemporaryDirectoryAllocator.dispose
I see no reason to hold off on this PR just because jenkinsci/jenkins#4447 is stalled. |
|
||
private void delete(Path p) throws IOException { | ||
LOGGER.fine(() -> "deleting " + p); | ||
if (Files.isDirectory(p, LinkOption.NOFOLLOW_LINKS)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably also a junction which I think may be used in some test case and FIlePath
respects.. (FIles.readAttributes
and isOther
- as a general well it is not a normal directory)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not know much about junctions. Would they ever really be used in $JENKINS_HOME
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sure something uses them as we have specific code in Jenkins...
https://github.com/jenkinsci/jenkins/blob/715cdb15b3e855f8b6115aa02200860ed6caf49d/core/src/main/java/hudson/Util.java#L323-L343
I have not come across a real life example, but I'm guessing that it is for a reason?
Maybe it is just an easy way in Jenkins to put some subset of Job
s in a different drive / pool etc and would not actually be done inside a workspace, or a build directory by jenkins (I do not know if zipping on windows copies the Junction or not, so if a workspace was coppied from an agent where the build created a junction if that would be replcicated on a master).
ec2 plugin seems to use them for something?
https://github.com/jenkinsci/ec2-plugin/blob/20f0c2406d62ddbd0d005a2fb15f3f9bb95b3f20/src/main/java/hudson/os/WindowsUtil.java#L109-L121
and the workspacebrowser has a test to prevent traversing them IIRC (so there is at least one use in Jenkins where a workspace will have junctions) https://github.com/jenkinsci/jenkins/blob/9330635821cbcb430b4223b471692f2c9ae862db/test/src/test/java/hudson/model/DirectoryBrowserSupportTest.java#L617
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might be some obscure use case in production servers, but I doubt this would affect functional tests. If there is some plugin which does create a junction during a test for some reason, then it can explicitly remove it before generic cleanup, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh now https://github.com/jenkinsci/jenkins/pull/8006/files#r1199177115 makes sense
…rness into TemporaryDirectoryAllocator.dispose
Tested successfully in jenkinsci/jenkins#8006 which I think is good enough. |
src/main/java/org/jvnet/hudson/test/TemporaryDirectoryAllocator.java
Outdated
Show resolved
Hide resolved
|
||
private void delete(Path p) throws IOException { | ||
LOGGER.fine(() -> "deleting " + p); | ||
if (Files.isDirectory(p, LinkOption.NOFOLLOW_LINKS)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh now https://github.com/jenkinsci/jenkins/pull/8006/files#r1199177115 makes sense
src/main/java/org/jvnet/hudson/test/TemporaryDirectoryAllocator.java
Outdated
Show resolved
Hide resolved
…ryAllocator.dispose` change) (#8006) * Testing `TemporaryDirectoryAllocator.dispose` change * `QueueTest.pendingsConsistenceAfterErrorDuringMaintain` should wait for completion of any builds it started * Close a `FileOutputStream` in `LauncherTest.remotable` * `DirectoryBrowserSupportTest.junctionAndSymlink_outsideWorkspace_areNotAllowed_windowsJunction` to clean up junctions it created * Reverting temporary dep on jenkinsci/jenkins-test-harness#198 * Commenting reason for `rmdir /s /q` #8006 (review)
Caused #591. |
Caused JENKINS-71406. |
Well, if this change exposes bugs in code, it's not this change fault that other code is buggy. |
I agree that it is not the fault of this change that other code has bugs. However, it seems important to the overall progress of the project that when general behavior (tests passing reliably) regresses, it is better to either fix the problems that have been exposed by the change or revert the change that exposed the problems. Remaining for an extended period in a state where tests are flaky (the problem is exposed but not resolved) will reduce our ability to trust the tests and our ability to add new capabilities. It is a good thing that we see the problems, but if we can't resolve the problems that we now see (in a reasonable amount of time and effort), then I think it is healthier for the project to return to hiding the problems (by reverting the change) rather than slow further progress with the distraction of seeing those problems. |
Commented in Jira. Please keep discussion there. |
Caused #612. |
@jglick This PR is causing problems in https://github.com/jenkinsci/copyartifact-plugin |
@jglick This PR is causing problems in jenkinsci/workflow-cps-global-lib-http-plugin#167 |
Experience in jenkinsci/jenkins#4447 shows that the
FilePath
- and thusPathRemover
-based implementation does not work reliably in Windows CI after #166, and we get stuff like #185 which is making things more complicated than it really needs to be. In a test, we