-
Improvement
-
Resolution: Not A Defect
-
Minor
-
None
At least for SCMs that require a workspace to poll, it can happen that the impl needs to have a Node instance corresponding to the slave on which the workspace resides, and more to the point, on which the Launcher runs commands.
For example, if the impl uses a ToolInstallation to abstract the operation of the SCM, it will need to call NodeSpecific.forNode to get a local version of the SCM executable. See MercurialSCM.compareRemoteRevisionWith.
Launcher.getComputer() looks like the natural method but it is deprecated and may not work. Computer.getCurrent().getNode() will not work since we are not inside a build and not running on an executor.
The workaround is to use project.getLastBuiltOn(). This will match what AbstractProject.poll in fact was using, so long as a new build has not appeared in the meantime - a possible race condition.
Fix unclear; SCM.poll should perhaps be given a Node. Then some variant of compareRemoteRevisionWith (and perhaps also calcRevisionsFromBuild) could be created that passes in a Node; or the Node could be available in some other way, such as a protected final method in SCM reading a ThreadLocal<Node>, etc.
- is blocking
-
JENKINS-14247 Master Executor Needed for SCM polling even with slaves
- Closed