Webhook 通用触发插件

本文首发于：Jenkins 中文社区

原文连接    做者：Tomas Bjerre

译者：wenjunzhangp

Webhook 通用触发插件

介绍通用 Webhook 触发插件，使用 Webhook 插件构建 Jenkins 自动化服务

这篇文章将介绍我在 Jenkins 上遇到的一些常见问题，以及如何经过开发通用 Webhook 触发插件来解决这些问题。

问题 

在使用 Jenkins 工做时，我常常遇到一样的问题：

• 代码重复和安全性-每一个仓库中的 Jenkinsfiles。
• 分支不是功能-master 上的参数化任务一般会混合与不一样功能相关的参数。
• 记录不良的触发器插件-记录正常服务但记录不佳的使用插件

代码重复和安全性 

每一个 Git 仓库中都有 Jenkinsfiles，使开发人员可使这些文件分开。开发人员 push 他们的项目，而且很难维护共享代码的模式。

我几乎用共享库解决了代码重复问题，可是它不容许我设置必须遵循的严格模式。任何开发人员仍然能够决定不调用共享库提供的功能。

还容许开发人员运行 Jenkinsfiles 中的任何代码的安全性方面。例如，开发人员可能会打印从凭据收集的密码。让开发人员在 Jenkins 节点上执行任何代码对我来讲彷佛不合适。

分支不是功能 

在 Bitbucket 中有项目，每一个项目都有 git 仓库的集合。像这样：

• PROJ_1

  • REPO_1
  • REPO_2

• PROJ_2

  • REPO_3

让咱们考虑一下咱们要为这些仓库提供的一些功能：

• pull request 验证
• 构建快照（若是须要的话，也能够预发布）
• 构建发布

若是开发人员习惯于在 Bitbucket 中像这样组织仓库，咱们是否应该在 Jenkins 中以一样的方式组织它们？并且，若是他们浏览 Jenkins，是否不该该为每种功能（例如 pull-request，snapshot 和 release）找到一份构建任务？每一个具备仅与该功能相关的参数的任务。我认同！像这样：

• / - Jenkins root

  • /PROJ_1 - 一个文件夹，列出 git 仓库。

    • /PROJ_1/REPO_1 - 一个文件夹，列出与该仓库相关的任务。
    • /PROJ_1/REPO_1/release - 一份构建任务，执行发布。
    • /PROJ_1/REPO_1/snapshot - 一份构建任务，执行快照发布。
    • /PROJ_1/REPO_1/pull-request - 一份构建任务，验证 pull-request。
• …​

在此示例中，snapshot 和 release 任务均可以在同一 git 分支上工做。不一样之处在于它们提供的功能。它们的参数能够很好地记录下来，由于您没必要混合与发行版和快照相关的参数。使用多分支流水线插件没法作到这一点，在多分支流水线插件中，您将参数指定为每一个分支的 properties。

文献资料 

Webhooks 一般在提供它们的服务中有据可查。例如：

• Bitbucket Cloud
• Bitbucket Server
• GitHub
• GitLab
• Gogs 和 Gitea
• Assembla
• Jira

令我困扰的是，即便我理解了这些 webhooks，我也没法使用它们。由于我须要在所使用的插件中进行开发，以便提供从 Webhook 到构建的任何值。从 PR 到实际发布，该过程可能须要几个月的时间。这样简单的事情实际上应该不是问题。

解决方案 

个人解决方案几乎能够追溯到基本知识：咱们有一个自动化服务（Jenkins），咱们想在外部 Webhooks 上触发它。咱们想从该 Webhook 收集信息并将其提供给咱们的构建。为了支持它，我建立了通用 Webhook 触发器插件。

仓库中提供了最新文档，而且有一个完整的示例，其中使用 configuration-as-code 实现了 GitLab。在这里查看仓库。

代码重复和安全性 

我制定了全部开发人员都必须遵循的约定。而不是让开发人员从 Jenkinsfiles 显式调用基础结构。遵循一些规则，例如：

• 全部的 git 仓库都应该从仓库的根开始构建。

• 若是包含 gradlew

  • 使用 ./gradlew build 完成构建
  • 使用 ./gradlew release 完成发布
  • ……等等

• 若是包含 package.json

  • 使用 npm run build 完成构建
  • 使用 npm run release 完成发布
  • ……等等

有了这些规则，流水线就能够彻底通用，而且在仓库中不须要 Jenkinsfiles。因为某些缘由，某些 git 仓库可能须要禁用测试用例。这能够经过容许仓库添加一个特殊文件，也就是 jenkins-settings.json 来解决，让基础架构发现其内容并对其采起行动。

即便没有执行 CI，这也能够帮助开发人员。当他们克隆一个新的，未知的仓库时，他们将知道能够发出哪些命令及其语义。

分支不是功能 

我实现：

• Jenkins 任务配置-使用任务 DSL。
• Jenkins 的构建过程-使用 Pipelines 和共享库。

经过与 Job DSL 中的 git 服务集成，我能够自动找到 git 仓库。我建立动态组织在文件夹中的任务。还调用 git 服务来设置触发这些任务的 webhooks。任务是普通的流水线，不是多分支，它们不使用 Git 中的 Jenkinsfile，而是使用 Job DSL 在任务中配置的 Jenksinfile。所以，全部任务配置和流水线均受版本控制。这一切都在这里发生。

文献资料 

该插件使用 JSONPath 以及 XPath 从 JSON 提取值并将其提供给构建。让用户从 webhook 中选择所需的内容。它还具备一个正则表达式过滤器，以容许在某些状况下不触发。

该插件不是很大，只是 webhook、JSONPath/XPath 和正则表达式之间的粘合剂。全部这些部分都已被很好地记录下来，我会尽力维护该插件。这是一个很是有据可查的解决方案！

参考