|
|
 |
|
|
|
|
Issue Type:
|
 New Feature
|
|
Affects Versions:
|
current |
|
Assignee:
|
vjuranek
|
|
Components:
|
ws-cleanup |
|
Created:
|
19/Sep/12 4:41 PM
|
|
Description:
|
We are facing sometimes the situation that a unit test job is successful and a mail with success is sent out to the developers but when they look into their dashboards the job is marked as failure because something went wrong when deleting the workspace on a slave. This is somehow confusing and we would be glad if there could be an option to ignore failures of the ws-cleanup plugin for the overall job outcome.
22:57:42 Recording fingerprints
22:57:42 Email was triggered for: Success
22:57:42 Sending email for trigger: Success
22:57:42 Sending email to: [hidden email]
22:57:43
22:58:14 Deleting project workspace... ERROR: Publisher hudson.plugins.ws_cleanup.WsCleanup aborted due to exception
22:58:14 hudson.util.IOException2: remote file operation failed: C:\Workspace\Some_Tests at hudson.remoting.Channel@4260877a:SLAVE7
22:58:14 at hudson.FilePath.act(FilePath.java:838)
22:58:14 at hudson.FilePath.act(FilePath.java:824)
22:58:14 at hudson.FilePath.deleteRecursive(FilePath.java:908)
22:58:14 at hudson.plugins.ws_cleanup.WsCleanup.perform(WsCleanup.java:68)
22:58:14 at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27)
22:58:14 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717)
22:58:14 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:692)
22:58:14 at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
22:58:14 at hudson.model.Run.execute(Run.java:1546)
22:58:14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
22:58:14 at hudson.model.ResourceController.execute(ResourceController.java:88)
22:58:14 at hudson.model.Executor.run(Executor.java:236)
22:58:14 Caused by: java.io.IOException: Unable to delete C:\Workspace\Some_Tests\Bin\Debug - files in dir: [C:\Workspace\Some_Tests\Bin\Debug\XmlSchemaUtilitiesTests.pdb]
22:58:14 at hudson.Util.deleteFile(Util.java:238)
22:58:14 at hudson.Util.deleteRecursive(Util.java:289)
22:58:14 at hudson.Util.deleteContentsRecursive(Util.java:200)
22:58:14 at hudson.Util.deleteRecursive(Util.java:280)
22:58:14 at hudson.Util.deleteContentsRecursive(Util.java:200)
22:58:14 at hudson.Util.deleteRecursive(Util.java:280)
22:58:14 at hudson.Util.deleteContentsRecursive(Util.java:200)
22:58:14 at hudson.Util.deleteRecursive(Util.java:280)
22:58:14 at hudson.Util.deleteContentsRecursive(Util.java:200)
22:58:14 at hudson.Util.deleteRecursive(Util.java:280)
22:58:14 at hudson.FilePath$11.invoke(FilePath.java:910)
22:58:14 at hudson.FilePath$11.invoke(FilePath.java:908)
22:58:14 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2200)
22:58:14 at hudson.remoting.UserRequest.perform(UserRequest.java:118)
22:58:14 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
22:58:14 at hudson.remoting.Request$2.run(Request.java:287)
22:58:14 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
22:58:14 at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
22:58:14 at java.util.concurrent.FutureTask.run(Unknown Source)
22:58:14 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
22:58:14 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
22:58:14 at hudson.remoting.Engine$1$1.run(Engine.java:60)
22:58:14 at java.lang.Thread.run(Unknown Source)
22:58:14 Notifying upstream projects of job completion
22:58:14 Finished: FAILURE
|
|
Environment:
|
Windows 2008 Server R2 64 Bit for the slave, Win 7 64 Bit for master
|
|
Project:
|
Jenkins
|
|
Priority:
|
 Major
|
|
Reporter:
|
Dirk Kuypers
|
|
|
|
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
Locked
We have the same problem. For us, it's a big blocker. Because the job fails due to workspace cleanup, the next part of the build/test chains won't execute because the job has a status of failed.
Ideally, it would be best to fix the exception so that it doesn't happen and the builds never fail. But if there's no way to fix the exception, then a way to keep the build from being marked as failed would be the next best thing.