Question

在正常的自由式项目中，我将SCM插件配置为指向我要发布的Git仓库，并启用＆＃34;轮询SCM＆＃34;选项，它允许我配置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轮询的任何想法？

Answer 1

我通过大量的研究和实验解决了这个问题。这份文档使我走上正轨：https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md。它说：

多个SCM支持轮询（一个或多个中的更改将触发新版本），并且再次根据上一版本工作流中使用的SCM完成。“

这意味着Jenkins工作流仍支持SCM轮询，但与普通的自由式项目不同，您必须在开始侦听SCM更改之前手动运行一次。这是有道理的，因为SCM是在Groovy代码中定义的;直到他们跑了一次才知道他们。

这方面的一个棘手要素是您可以在工作流程中定义许多SCM。例如，我有三个：一个用于服务本身，一个部署脚本和Groovy工作流DSL。默认情况下，对这三个SCM中的任何一个进行更改都会导致“SCM poll”选项触发构建，这可能是不可取的。幸运的是，在Groovy代码中的“git”步骤上设置“poll：false”选项将禁用该repo上的轮询。如果您正在从SCM读取Groovy DSL，则可以通过单击Jenkins UI中的“其他行为”并添加“不要在提交通知上触发构建”来禁用对该存储库的轮询。

另一个棘手的问题是Stash web hook插件默认包含RESTful URL中提交的SHA1哈希代码，它触及Jenkins。不幸的是，当Jenkins尝试拉出你可能定义的多个SCM中的任何一个时，错误地使用相同的提交代码。哈希码当然只与一个SCM相关，因此它会中断。你可以通过在Stash web hook插件中设置“Omit SHA1 Hash Code”来解决这个问题。然后Jenkins将使用你在每个SCM中构建的任何分支上的最新提交。

如何使用Jenkins Workflow插件进行SCM轮询

1 个答案: