|
||||||||
|
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.
Let me amend that. In 2.4 and earlier, even though compareRemoteRevisionWith was being passed a null workspace (because it affirms it does not requiresWorkspaceForPolling), it nonetheless looked up the slave to run the last build and, if still online, did its polling from there! (Not in any particular working directory, and not locking the workspace, but on the same machine.) So it would have polled from the master despite doing checkouts on a slave only under some conditions: -Dhudson.scm.SubversionSCM.pollFromMaster was passed as a startup option; the slave has since been disconnected; all builds got deleted; etc.
Now in 2.5, this change plus this correction mean that polling is unconditionally done on the master, and so the flags to control that are dead code, and CompareAgainstBaselineCallable is passed to a LocalChannel which calls it directly. Thus the issue of polling without requiring a slave was fixed inadvertently.
The question remains whether the change was desirable or not. Generally it is cheaper and better to do polling from the master. There are however uncommon reasons why you might want to poll on a slave, for example: the master has no physical access to the Subversion server due to network topology; Subversion credentials are kept in ~/.subversion/auth/ only on slaves, not using the Credentials plugin. Perhaps the ability to poll from the slave ought to be reintroduced, ideally as a per-job UI option. (requiresWorkspaceForPolling probably needs to remain off, since it is not necessary to lock the workspace to poll, merely to run from the same machine and user account.)
Anyway, rereading the original description of this issue, it was about something else entirely: the ability to use the Jenkins plugin only for polling, but performing actual checkout operations from the job’s build script. This is simply not supported in Jenkins generally, not the fault of the Subversion plugin.