调试这类东西时需要检查的一些事情：

• 检查你的Jenkins日志，看看Jenkins是否收到了钩子，并出于某种原因决定不采取行动。
• 通过单击管理Jenkins ->配置全局安全性来检查Jenkins安全性。尽可能多地打开事情，看看这是否会改变什么。
• 确保将更改推送到主分支。为了简单起见，在使用此方法时，可以考虑使用**作为分支说明符。
• 通过单击Manage Jenkins -> Global Tool Configuration，确保在Jenkins主机上正确配置了Git
• 确保您提供的凭据的用户可以管理钩子并从您感兴趣的仓库中拉取。
• 在Jenkins中手动运行作业，确保它工作正常。
• 运行作业后，它应显示为受保护分支/必需状态中的一个选项。在你的仓库中，点击设置->分支，在分支部分选择你的分支，点击合并前需要状态检查通过选项，你的作业应该会出现在出现的列表中。

Webhooks可以说是Jenkins最难测试的特性，因为有这样的陷阱（可能他们的列表是不完整的）：
1.必须为每个管道构建创建新的git commit / git push（重复以前的构建不会触发新的构建，即使webhook已经正确设置-参见下文）。
1.在正确设置webhook后进行的第一次构建必须是手动的（不可能从webhook本身进行引导）。
1.在正确设置webhook后进行的第一次构建必须完全成功，更改才能生效，webhook才能开始工作。这也会导致Jenkins错过在新创建的管道的第一次构建期间发出的所有传入请求。
1.对于新创建的管道，请确保检查Build Triggers > GitHub hook trigger for GITScm polling（必须在每个管道中启用）。

• 更多信息 *

请注意，不可能再次使用相同的构建条件触发构建（至少使用webhook）。因此，你可能已经有了一个正确的webhook设置，但除非你创建一个新的git commit并将其推送到Github上的远程repo，否则你不会发现它可以工作。如果你试图一遍又一遍地重复一些旧的推送，只需在Github的Webhooks / Manage webhook页面上的Recent delivery部分按下“Redivery”按钮，Jenkins将永远不会超越“poke”repo阶段，因为它需要检测SCM更改以触发新的构建：

Received PushEvent for https://github.com/mirekphd/<REPO_NAME> from <GITHUB_IP> ⇒ <JENKINS_URL>/github-webhook/

Apr 16, 2021 9:42:12 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
Poked <REPO_NAME>

Apr 16, 2021 9:42:13 PM INFO com.cloudbees.jenkins.GitHubPushTrigger$1 run
SCM changes detected in <REPO_NAME>. Triggering #236

有关第2）和第3）点的更多信息：见原始source。