在一个普通的freestyle项目中，我将SCM插件配置为指向我想要发布的Git repo，并启用"轮询SCM"选项，该选项允许我配置Stash webhook，以便在repo发生更改时告诉Jenkins。通过这种方式，只要将更改推送到回购，就可以触发作业。
但是，当我使用工作流而不是自由式项目时，我需要构建的代码的SCM是在groovy工作流脚本中以编程方式指定的，这意味着它没有监听Stash webhook。相反，直接在工作流中配置的SCM是groovy脚本本身的SCM，这与我试图构建/发布的代码库不同，所以我不希望触发器基于此。
node('docker_builder') {
git url: serviceRepo
releaseVersion = getVersion()
pipelineSpec = getPipelineSpec()
sh "./gradlew clean build pushDockerImage"
}
关于如何在使用工作流插件时实现SCM轮询，有什么想法吗？
我通过大量的研究和实验解决了这个问题。这份文件让我走上了正轨：https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md.上面写着：
支持在多个SCM之间进行轮询（一个或多个SCM中的更改将触发新的构建），并根据工作流的上一个构建中使用的SCM再次进行轮询。"
这意味着Jenkins工作流仍然支持SCM轮询，但与普通的自由式项目不同，在它开始侦听SCM更改之前，您必须手动运行它一次。这是有意义的，因为SCM是在Groovy代码中定义的；他们只有跑过一次才为人所知。
其中一个棘手的因素是，您可以在工作流中定义许多SCM。例如，我有三个：一个用于服务本身，一个部署脚本，以及Groovy工作流DSL。默认情况下，对这三个SCM中的任何一个的更改都会导致"SCM轮询"选项触发生成，这可能是不可取的。幸运的是，在Groovy代码中的"git"步骤上设置"poll:false"选项将禁用对该repo的轮询。如果您正在从SCM读取Groovy DSL，那么您可以通过单击Jenkins UI中的"其他行为"并添加"不要触发基于提交的构建通知"来禁用对该repo的轮询。
另一个棘手的因素是，Stash web挂钩插件默认情况下会在Jenkins使用的RESTful URL中包含提交的SHA1哈希代码。不幸的是，Jenkins在尝试提取您可能定义的多个SCM中的任何一个时，都会错误地使用相同的提交代码。哈希代码当然只与一个SCM相关，因此它会中断。你可以通过在Stash网络挂钩插件中设置"省略SHA1哈希代码"来解决这个问题。然后，Jenkins只会在您在每个SCM中构建的任何分支上使用最新的提交。