Hi,

Thanks for that interesting link.
You're right and we already worked on shortening our paths. We also wrote a few scripts which automatically map the current path on a new drive letter in order to reduce the risk to encounter that ridiculous Windows issue. But anything we do is only delaying the issue. And it came back with that job.

The point here is:

  • the job is a "matrix" job so the working dir path is longer (C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS). Reducing too much the job name is an issue when you have 400 jobs.
  • in the currently failing path, the only part we could still reduce is not very long: nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss.

The deletion fails in Java File.delete() so there's no quick solution for that issue. But we could imagine some workarounds to reduce the times it's happening:

  • Jenkins could mount the working directory on a new drive letter,
  • Jenkins could propose to use a specific short path when on Windows (ie c:\ws\buildNumber or c:\ws\jobName\buildNumber),
  • when failing to delete a file on Windows, the code could try to fallback on calling a delete windows command (rmdir /s /q path/to/file),
  • ...
    I can't see a "clean" solution but anything that could help to shorten the path when working on windows would help...
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

Reply via email to