>Does it happen with any other job than the specific job which shows the problem?
As far as I can tell it doesn't. The job is split through a user defined axis into 7 separate jobs so it's run on multiple slaves. This is done so actually finishes in one hight. This splits the tasks we test into 7 about equal parts. The configuration does not state the workspace should be wiped.

The interesting thing is that this loss of .git and .gitignore happens only to one of the parts one one of the slaves out of the 7, seemingly at random. Last time it was the 2nd part. Before we split it into 6 parts and then the failing one was usually the 6th one.

>Do you have a history of the configuration of the problem job?
Not really, but then again it is our nightly, it's been set up the same way(excluding the number of parts) for a very long time.

>Do your users have the permission to use the "Wipe out workspace" link that is usually available with each job?
Yes, they do, but it's only a few developers and they know about our problems with builds.

>Could one of the users have chosen to wipe out that workspace?
Unlikely. Besides, wouldn't that delete the WHOLE workspace(or to be exact, it would try, but fail on the jail which is owned by root), and not just .git and .gitignore? Also, wouldn't that wipe the workspace only on the Jenkins master? The .git and .gitignore files disappear only from the slaves.

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 jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to