Community
Participate
Working Groups
Created attachment 214549 [details] reponse from trying to wipe workspace This is using the Hudson interface itself, nothing fancy. There's an option under our job specific page to see the workspace: https://hudson.eclipse.org/hudson/view/Eclipse%20and%20Equinox/job/JUnit-win2/ and if you expand that, there is an option to "wipe it". If I try that, I get an error, which I'll attach. I can make a little progress with the "junk" there, but will need it cleaned up soon.
This has happened before. The .git folder receives the Read-Only bit for some reason. Perhaps it's a git client setting or something.... I've cleared the bit -- can you try wiping the workspace now?
I just tried again (didn't read your reply until now) and it failed again ... though, I've used git a number of times on it, so it it'd not be surprising that git would "reset" the bit to be readonly. java.io.IOException: Unable to delete c:\hb\workspace\JUnit-win2\org.eclipse.releng.eclipsebuilder\.git\objects\pack\pack-e1219dba877f48edd90fb0bd92e4348dbc591be8.pack
Now when I try to start a job, (tried 3 or 4 times) I always get the error similar to that reported in bug 377433 (though, it was on a linux box). Started by user anonymous Building remotely on windows7tests Checkout:JUnit-win2 / c:\hb\workspace\JUnit-win2 - hudson.remoting.Channel@55e0740e:windows7tests Using strategy: Default Last Built Revision: Revision 1338d3ccc49f9cccc83d3c53d8aa9201e9b737e6 (origin/master) Checkout:org.eclipse.releng.eclipsebuilder / c:\hb\workspace\JUnit-win2\org.eclipse.releng.eclipsebuilder - hudson.remoting.LocalChannel@ab64e3 FATAL: One of setGitDir or setWorkTree must be called. java.lang.IllegalArgumentException: One of setGitDir or setWorkTree must be called. at org.eclipse.jgit.lib.BaseRepositoryBuilder.requireGitDirOrWorkTree(BaseRepositoryBuilder.java:538) at org.eclipse.jgit.lib.BaseRepositoryBuilder.setup(BaseRepositoryBuilder.java:506) at org.eclipse.jgit.storage.file.FileRepositoryBuilder.build(FileRepositoryBuilder.java:89) at hudson.plugins.git.GitAPI.<init>(GitAPI.java:92) at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:853) at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:845) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1960) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:283) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source)
So ... you can try read bit again if you'd like and I'll pay attention and try to remove myself .... or, if you wouldn't mind ... you could just delete everything under c:\hb\workspace\JUnit-win2\ and I'll start fresh .. and while we'll still have the long term problem, that might hold us through milestone week?
I had to restart the client as windows kept reporting that a pack file was in use by the JVM when I tried to delete the directory. Everything should be 'back to normal' now. -M.
I am able to build again and have a shiny new workspace. Should we leave this open until we know the "long term" fix for deleting the workspace? Or ... think this was a one-time problem and in future I should be able to remove workspace myself? (I'm a little afraid to try now :)
These issues have the 'appearance' of a Hudson bug(or bugs). But you should be able to delete the workspace(well, Hudson should be able to at least). I'll close this and we can re-open(or create a new one) if something goes wrong again. -M.
Created attachment 214845 [details] response same problem again.
And now seeing same problem with our other "windows test job" (which is to test our 3.8.0 builds). FATAL: remote file operation failed: c:\hb\workspace\JUnit-win at hudson.remoting.Channel@4ad5b395:windows7tests hudson.util.IOException2: remote file operation failed: c:\hb\workspace\JUnit-win at hudson.remoting.Channel@4ad5b395:windows7tests at hudson.FilePath.act(FilePath.java:754) at hudson.FilePath.act(FilePath.java:740) at hudson.FilePath.deleteRecursive(FilePath.java:824) at hudson.model.AbstractProject.cleanWorkspace(AbstractProject.java:1774) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:419) at hudson.model.Run.run(Run.java:1367) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) Caused by: java.io.IOException: Unable to delete c:\hb\workspace\JUnit-win\org.eclipse.releng.eclipsebuilder\.git\objects\pack\pack-145b4abe4589cf58a806d2c3d48df23fd901c197.pack at hudson.Util.deleteFile(Util.java:263) at hudson.Util.deleteRecursive(Util.java:305) at hudson.Util.deleteContentsRecursive(Util.java:224) at hudson.Util.deleteRecursive(Util.java:304) at hudson.Util.deleteContentsRecursive(Util.java:224) at hudson.Util.deleteRecursive(Util.java:304) at hudson.Util.deleteContentsRecursive(Util.java:224) at hudson.Util.deleteRecursive(Util.java:304) at hudson.Util.deleteContentsRecursive(Util.java:224) at hudson.Util.deleteRecursive(Util.java:304) at hudson.Util.deleteContentsRecursive(Util.java:224) at hudson.Util.deleteRecursive(Util.java:304) at hudson.FilePath$9.invoke(FilePath.java:826) at hudson.FilePath$9.invoke(FilePath.java:824) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1960) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:283) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source) So, this is not a blocking problem for us. I'm fairly sure we have to "clean" the workspace before each build, so we won't be able to make any progress testing on windows with this problem. Naturally, if you have some suggestions on things we could do differently on our end, let me know.
(In reply to comment #9) > So, this is not a blocking problem for us. So, this is NOW a blocking problem for us.
We could/should perhaps try updating git on the windows slave, in case this is a git bug.
(In reply to comment #11) > We could/should perhaps try updating git on the windows slave, in case this is > a git bug. Wouldn't hurt, but, the other thing I'll try is to put my actual tests in a subddirectory named "workarea" and that will be the only directory I'll be sure to clean each time. That's still a hacky workaround, since a) should be able to clean workspace, b) if can't delete the file due to dangling process, then than dangling process is likely to interfere with tests and/or slow them down if they "build up". So, maybe we'll do these things in parallel and one or both will help?
I've installed Git 1.7.10. A quick look at the workspace permissions shows that both directories were marked 'read-only' and when I removed that wiping out the Junit-win workspace failed with the 'pack file in use by Java' error. I've removed the workspace contents, and if this happens again I think we should strongly consider filing this as a bug against Hudson(although perhaps the upgrade due this summer will resolve the issue). -M.
And, I've added a "workarea" subdirectory to delete. There is less reason to delete the git repo we check out. So, I don't think this is "blocking" any longer. But, will leave open until we actually test cleaning the whole workspace and then we'll know if still a problem or not. From a little searching on the internet, seemed like this was a problem on windows, hudson or not, so may be something "deeper" ... perhaps something about git needs "special permissions" from windows, or perhaps there is some combination of problems.
When is Windows NOT part of the problem?
Getting this error again. To make matters worse, I've decided for us (platform) to reliably run our junit tests, we do need to wipe the workspace before checking out (cloning) git repo each time (the 'workarea' I tried wasn't enough) ... so ... if we can't do that ... we're sort of hosed on testing with hudson, on windows. works find on linux and the mac. Right now, I get the following error when trying to start a job, but this followed a run where I tried to wipe the workspace first (its an option under the "advanced" Git button) and that run produced the typical " can't delete some .git... pack file " Current error: Checkout:org.eclipse.releng.eclipsebuilder / c:\hb\workspace\JUnit-win\org.eclipse.releng.eclipsebuilder - hudson.remoting.LocalChannel@118a2e9 FATAL: One of setGitDir or setWorkTree must be called. java.lang.IllegalArgumentException: One of setGitDir or setWorkTree must be called. at org.eclipse.jgit.lib.BaseRepositoryBuilder.requireGitDirOrWorkTree(BaseRepositoryBuilder.java:538) at org.eclipse.jgit.lib.BaseRepositoryBuilder.setup(BaseRepositoryBuilder.java:506) Suggestions?
I checked and the 'parent' directory also had the read only bit set, so I cleared it. I did some digging and I see what David was referring to(this being some kind of issue in Windows), but I didn't see anyone with an 'actual' fix. Everyone basically recommended what we're already doing. -M.
Would using the chattr command work? My DOS is a bit far away...
(In reply to comment #18) > Would using the chattr command work? My DOS is a bit far away... Don't know, but I have what may be a better solution. I don't really want a repo, I just want the files! (want to hear the long story?) I spent the weekend trying to find some way just to "export" the files, like cvs (or svn) can do, but apparently git does not do that (directly), but found one site that recommended using git archive --format=tar and apparently, that might work if working directly on build machine (using file paths) http://aniefer.blogspot.com/2011/01/building-from-git.html But that doesn't help with Hudson slaves, and even using SSH I could not get it to work remotely: git archive ... ssh://david_williams@git.eclipse.org/gitroot/platform/eclipse.platform.releng.eclipsebuilder.git Not allowed to do git command '/usr/local/bin/git-upload-archive' at /usr/local/bin/committer_shell line 125. fatal: The remote end hung up unexpectedly (in case your interested in who's been cause weird security logs on your end :) Was about to open a bug "to allow it", BUT THEN, found bug 329841 !! It appears I can get the code I need using ant or wget with a simple wget git.eclipse.org/c/platform/eclipse.platform.releng.eclipsebuilder.git/snapshot/master.zip and that avoids all that nasty .git directory stuff. So ... that's the direction I'm going to head down. I should be able to delete _those_ files very easily, and re-fetch when ever needed. For tests, who needs a repo! :) [I might have more questions, when I need to retrieve a specific "tagged" version ... but assume that'll be obvious.] P.S. to be able to use git archive would be kind of nice, but does seem like its done much, so maybe its old school? Or a security risk? I was trying git archive --format=tar --output=eb.tar --remote="ssh://david_williams@git.eclipse.org/gitroot/platform/eclipse.platform.releng.eclipsebuilder.git" --exec="/usr/local/bin/git-upload-archive" I'm guessing the "snapshot" function is doing that ... just with the right authority and/or location. If that 'snapshot' function is documented somewhere, that should be highlighted. (Might be? ... you know ... I'm a newbie).
I couldn't help myself, I was so excited I made a few notes in http://wiki.eclipse.org/Git#You_don.27t_need_Git_to_get_code_from_repository (please correct if I've misstated, but think this is possible because "we" use cGit?) I'll give this no-repo method a try soon, and suspect we'll end up closing this bug as "won't fix" (since no real fix) and if/when happens I, or others, can just ask intervention.
I think "not eclipse" is proper resolution for this bug? I'm sure there's some way to fix it with some sort of windows setting, or some way to open a "git bug" ... but, doesn't sound like hudson or much to do about it (other than the "manual" intervention). The chattr approach might work but a) I don't know anything about it either, and b) my guess is the "hudsonbuild" user might need to be given some special "admin" privileges or something less than desirable. Don't know. But, the solution of not using git at all, and simply "getting the files" is actually the right solution, in this case, for many reasons (IMHO), so I am happy with that ... and can be thankful that Windows has once again led me to learning so much about the best way to use computers. :)
