Community
Participate
Working Groups
Today Hudson presented me with the following error: Started by upstream project "aether-core-nightly" build number 77 Building remotely on windows7tests Checkout:windows7tests / c:\hb\workspace\aether-core-nightly\jdk\Java 6 R 21 64bit (SUN)\label\windows7tests - hudson.remoting.Channel@262b2310:windows7tests Using strategy: Default Last Built Revision: Revision 1d4a130715091c2ee0e604b66352d7260a90c565 (origin/master) Checkout:windows7tests / c:\hb\workspace\aether-core-nightly\jdk\Java 6 R 21 64bit (SUN)\label\windows7tests - hudson.remoting.LocalChannel@1e5a4b3 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:851) at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:843) 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) Googling for the error msg brought up http://issues.hudson-ci.org/browse/HUDSON-9005 which suggests to nuke the workspace to recover from the error. However, when I tried to do so via the Hudson UI, I ran into another error: Caused by: java.io.IOException: Unable to delete c:\hb\workspace\aether-core-nightly\jdk\Java 6 R 21 64bit (SUN)\label\windows7tests\.git\objects\pack\pack-2bd9a08c6c70a892cc9d181a646e6bb10085d010.pack I suspect the Hudson slave process is still holding a handle to that file, preventing its deletion. Once the slave gets restarted, I can hopefully nuke the workspace and fire a working build.
Ping
I've cleared your workspace.
(In reply to comment #2) > I've cleared your workspace. Thanks, but did you by chance clear the wrong workspace? When I went to check the workspace on the Windows slave it was still present. Trying to clean it failed with the known error. Just in case, I fired off a new build to see whether the original Git error was gone but that also persists. After the build failed, I tried to clean the workspace again and it failed on the same file as before: Unable to delete c:\hb\workspace\aether-core-nightly\jdk\Java 6 R 21 64bit (SUN)\label\windows7tests\.git\objects\pack\pack-2bd9a08c6c70a892cc9d181a646e6bb10085d010.pack
Hmmm... The C:\hb directory was flagged as 'read-only'. I'm unsetting that now... please stand by.
I _think_ I was able to clear this now. I noticed you have a build that has succeeded. Can you confirm?
(In reply to comment #5) > I _think_ I was able to clear this now. I noticed you have a build that has > succeeded. Can you confirm? Yes, three blue balls, thank you very much!
The issue is apparently back: https://hudson.eclipse.org/hudson/job/aether-core-nightly/jdk=Java%206%20R%2021%2064bit%20%28SUN%29,label=windows7tests/85/console Could you please double-check, whether the previously mentioned "read-only" filesystem issue, which I understood to be the root cause, is back? If the "read-only" state is/was not the cause, I assume the Git Hudson plugin has a bug in which case I will simply disable building on the Windows slave for the time being.
> Could you please double-check, whether the previously mentioned "read-only" > filesystem issue, which I understood to be the root cause, is back? Yes, the entire C:\hb folder is again flagged as read-only. Is there something in your job that may be setting this?
(In reply to comment #8) > Yes, the entire C:\hb folder is again flagged as read-only. Is there something > in your job that may be setting this? No, that would be news to me. Nothing in there should be touching file permissions/modes. FWIW, I'm developing on a Win7 box myself and didn't witness such an issue.
I outsourced CI on Windows to other infrastructure.
