|
||||||||
|
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/d/optout.
True, but if we assume the common case where jobs have their own isolated workspaces, then the only place a conflicting Git process could come from would be a previous run of the same job. For that to happen, the process would have to have somehow escaped Jenkins' process tracking/killing behaviour, something we've never seen in our particular environment and, I submit, is unlikely in general.
On the other hand, we have evidence that folks are still coming up against abandoned lock files, whether due to processes being KILL'ed or otherwise. So the optional "clean locks" behaviour would seem to at least put those folks in a better place than they're in now.
Either way, thank you for your work on Jenkins, much appreciated.