I was experiencing the same thing. One thing I came up with was to checkout the source code into a custom workspace so that previous runs wouldn't have to be deleted. I named the workspace using the build number so it was always unique. I did then have to run a cleanup job at night that took the windows slave offline and then I was able to wipe the workspaces.
Will On 10/02/13 13:37, Eric Pyle wrote: > We have the same problems with Git and pack files, as well as other > file locking issues on Windows slaves. For instance, if a build is set > to abort if it runs too long, and then we have Naginator retry the > build, some build process often keeps a handle on a file in the > workspace, causing the rebuild to fail. Like you, I've been dealing > with it using handle.exe and/or Process Explorer. I took a look at the > Clean Workspace source code at one point, because we usually clear the > workspace before building, and it looked there was potential to > improve its robustness. I never had time to follow up. > > Good luck! > > Eric > > > On 10/2/2013 2:20 PM, Scott Evans wrote: >> We have a Jenkins server (1.518) running on Ubuntu, with many plugins >> active, including "Jenkins GIT client plugin" 1.3.0 and "Jenkins GIT >> plugin" 1.5.0. What we're seeing is that in many cases on Windows >> agents of either Win7x64 or WinXP (not on Ubuntu), that often (but >> not always), a Git .pack file remains held open, causing subsequent >> builds to fail due to the Git .pack file remaining open. The only >> workarounds we have right now are to either bounce the agent java >> process on each windows machine that's showing the issue, or run a >> scheduled job which uses a handle.exe utility to find open .pack >> files and close them forcibly. Neither of these options are useful >> in the grand scheme of things. >> >> I've tried changing the options on our windows agent .bat launch >> scripts to include either: >> >> java -Xmx5g -Dorg.jenkinsci.plugins.gitclient.Git.useJGit=true -jar >> slave.jar -jnlpurl ... >> java -Xmx5g -Dorg.jenkinsci.plugins.gitclient.Git.useCLI=true -jar >> slave.jar -jnlpurl ... >> >> but neither option has caused any difference in behavior. In reading >> online it looks like 1.518 already sets useCLI=true as default, so >> I'm doubtful that it's making any difference anyway. >> >> Are others seeing this issue? If not, any suggestions on where to >> look to try and resolve this issue? >> >> Thanks in advance! >> Scott >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
