|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" 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.
I am seeing this as well. I tried upgrading to the latest Subversion plugin, but that has not helped. I have also tried changing the checkout strategy to always check out a fresh copy (instead of 'svn update' as much as possible), but that has not helped either.
The configuration where I am seeing this is the following: Jenkins master: Ubuntu 11.04, running Jenkins 1.436. I am seeing it on 2 different slaves for the same 3 jobs. Both slaves are running Ubuntu 10.04.3 LTS. There are 20 other jobs that do not exhibit this behavior, including jobs that use the same slaves as the problematic jobs.
The problem I'm seeing is that the top level workspace directory permission gets changed to 644 or 666. When this happens, the build fails, and I cannot wipe out the workspace from the Jenkins web interface. I need to SSH into the slave, cd /home/jenkins/workspace, then sudo rm -rf <job_name>. Then if I manually kick off the build via web interface, it works fine. If I manually kick off two builds back to back, they both work fine.
For whatever reason, the behavior coincides with nightly scheduled builds. Those fail everytime.
The other strange data point is that these three problematic jobs were working like clockwork for months. Now every scheduled nightly build fails due to this directory permissions issue.
This is a major problem in my opinion. How can we elevate this to get more attention?