|
||||||||
|
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/groups/opt_out.
Looked into this more, found this
http://jenkins.361315.n4.nabble.com/Perforce-force-syncing-for-no-reason-td2993189.html
It's not super obvious (I had issues similar to yours for a while), but Hudson automatically cleans up old workspaces that it thinks are stale... which works for some SCMs, but does not work well for Perforce at all in a configuration with multiple slaves.
(Basically what happens, I think: Two slaves A and B are in use. The last build of job Foo was on A, while the last build on B was old in the eyes of the Workspace Cleanup thingy. The workspace for build B is cleaned. Job Foo has a submitted change. Hudson polls with Perforce [on slave A] and finds there is a change. If slave A's executors are unavailable, the build is started on B. As far as Perforce knows, the workspace on B is there and only needs the updates since it's last old build. But, in fact, because it has been cleaned up, that's not enough.)
You are probably aware of this, but thought I'd share.