如何使用Jenkins Workflow插件使SCM轮询工作 [英] How to make SCM polling work with the Jenkins Workflow plugin

问题描述

在一个普通的自由式项目中，我将SCM插件配置为指向要发布的Git存储库，然后启用轮询SCM"选项，这使我可以配置Stash Webhook来告诉Jenkins是对该存储库的更改.这样，只要将更改推送到存储库中，就可以触发作业.

In a normal freestyle project, I configure the SCM plugin to point to the Git repo that I want to release, and I enable the "Poll SCM" option, which allows me to configure a Stash webhook to tell Jenkins whenever there has been a change to that repo. In this way, the job can be triggered whenever a change is pushed to the repo.

但是，当我使用工作流程而不是自由样式项目时，需要构建的代码的SCM是在groovy工作流程脚本中以编程方式指定的，这意味着它没有在监听Stash Webhook.相反，直接在工作流中配置的SCM是groovy脚本本身的SCM，它与我尝试构建/发布的代码库不同，因此我不希望触发器以此为基础.

But when I use a workflow instead of a freestyle project, the SCM of the code that I need to build is specified programmatically in the groovy workflow script, which means that it is not listening for the Stash webhook. Instead, the SCM that is configured directly in the workflow is the SCM of the groovy script itself, which is different than the codebase that I am trying to build/release, so I don't want the trigger to be based on that.

node('docker_builder') {
    git url: serviceRepo
    releaseVersion = getVersion()
    pipelineSpec = getPipelineSpec()
    sh "./gradlew clean build pushDockerImage"
}

关于使用工作流插件时如何实现SCM轮询的任何想法?

Any ideas about how to achieve SCM polling when using the workflow plugin?

推荐答案

我已经通过大量研究和实验解决了这个问题.该文档使我步入正轨: https://github.com/jenkinsci /workflow-scm-step-plugin/blob/master/README.md .它说:

I have resolved this question with lots of research and experimentation. This documentation got me on the right track: https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md. It says:

跨多个SCM支持轮询(一次或多次更改将触发新的构建)，并再次根据工作流的上一构建中使用的SCM完成轮询."

Polling is supported across multiple SCMs (changes in one or more will trigger a new build), and again is done according to the SCMs used in the last build of the workflow."

这意味着Jenkins工作流程仍支持SCM轮询，但是与普通的自由式项目不同，您必须先手动运行一次它，然后才能开始侦听SCM更改.这是有道理的，因为SCM是用Groovy代码定义的.他们只有运行一次才知道.

This means that SCM polling is still supported with a Jenkins workflow, but unlike a normal freestyle project, you have to run it once manually before it starts listening for SCM changes. This makes sense because the SCM's are defined in Groovy code; they are not known until they run once.

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

One tricky element of this is that you can define many SCM's in your workflow. For example, I have three: one for the service itself, a deployment script, and the Groovy workflow DSL. By default, changes to any of those three SCM's would cause the "SCM poll" option to trigger a build, which may not be desirable. Luckily, setting the "poll: false" option on the "git" step in the Groovy code will disable polling on that repo. If you are reading your Groovy DSL from an SCM, then you can disable polling on that repo by clicking "additional behaviors" in the Jenkins UI and adding "Don't trigger a build on commit notifications".

另一个棘手的元素是，默认情况下，Stash Web hook插件在其击中Jenkins的RESTful URL中包含提交的SHA1哈希码.不幸的是，Jenkins在尝试提取您可能已定义的多个SCM中的任何一个时，都会犯使用相同的提交代码的错误.哈希码当然仅与一个SCM相关，因此会中断.您可以通过在Stash Web挂钩插件中设置忽略SHA1哈希代码"来解决此问题.然后，Jenkins将只在您在每个SCM中构建的任何分支上使用最新的提交.

Another tricky element is that the Stash web hook plugin by default includes the SHA1 hash code of the commit in the RESTful URL that it hits Jenkins with. Unfortunately, Jenkins makes the mistake of using that same commit code when it tries to pull any of the multiple SCM's that you may have defined. The hashcode is of course only relevant to one SCM, so it breaks. You can get around this by setting "Omit SHA1 Hash Code" in the Stash web hook plugin. Then Jenkins will just use the latest commit on whatever branch you build from in each of your SCM's.

这篇关于如何使用Jenkins Workflow插件使SCM轮询工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！