SonarQube Webhook怎么配置 SonarQube Webhook推送失败怎么排查

SonarQube Webhook的配置，和推送失败时的排查，重点并不只是填进去一个回调地址就完成了，而是要去确认这个地址，能够被SonarQube的服务器正常访问到，并且接收的那一端，也能够正确地识别出推送过来的内容。Webhook这个东西，通常是用来把扫描完成、质量门禁的状态这一类结果，推送给Jenkins、GitLab、企业微信、钉钉，或者是公司内部的平台。SonarQube它支持项目这一级，和全局这一级的Webhook配置，项目级的，是可以在项目的设置里面去配，全局级的，则是可以在系统的管理里面去配。

一、SonarQube Webhook怎么配置

在配置Webhook以前，需要先确定好，推送的目标到底是什么。不同的接收端，它所需要的地址、鉴权的方式，还有处理数据的逻辑，都是不一样的，不能把Jenkins的回调地址、消息通知的接口，还有内部质量平台的接口，都混在一起，共用同一个地址。

1、先把推送的目标确认下来

需要先弄清楚，Webhook是要推送到流水线的平台，还是通知的机器人，又或者是内部的某个质量系统。如果是用在Jenkins的质量门禁上面，接收的地址，通常是由Jenkins的插件来提供的；如果是用在消息通知上面，那就需要有一个后端的服务，来接收SonarQube发过来的JSON内容，然后再把它转成对应平台所需要的消息格式。

2、去创建项目这一级的Webhook

进到项目设置里面的Webhooks页面，去创建一个新的Webhook，然后把名称和目标地址，都填进去。项目级的Webhook，要更加适合单个项目，去独立地推送结果。名称这边，最好是能把项目的名字，和接收端的名字都包含进去，比如order-service-jenkins这种形式，后面在做排查的时候，就能很快地判断出，它对应的是哪一个系统。目标的地址，需要使用接收端那边，真实能够访问到的HTTP或者HTTPS地址，不能只是填一个本机的localhost地址，除非SonarQube和接收端，是装在同一台机器上面的。

3、去设置全局的Webhook

全局的Webhook，比较适合用在，有好几个项目，都需要把结果推送到同一个平台的场景，比如统一的那个质量看板，或者是统一的流水线服务。有一点需要留心的是，项目级的和全局级的Webhook，是有可能同时都生效的，要是配置得太多了，就会造成重复的推送，所以最好是提前，就把推送的范围给规划好。

二、SonarQube Webhook推送失败怎么排查

在Webhook推送失败的时候，不能只是盯着SonarQube页面上显示的那个失败的状态去看。一个更加稳当的搞法，是按照网络、地址、接收端的状态、鉴权，还有负载的内容，这样一层一层地去进行排查。

1、去检查一下目标的地址

先要去确认，Webhook的这个地址，是能够从SonarQube所在的服务器上，正常访问到的，而不能只是在个人的电脑上，能够访问到。有很多失败，都是来自于网络的隔离、防火墙、容器的网络、反向代理，或者是域名解析这些方面的问题。可以先在SonarQube所在的那台服务器上面，直接去访问一下目标的地址，确认一下，不是那种本地的浏览器能通，可服务器这边，却偏偏不通的情况。

2、去检查一下接收端的状态

接收的那一端，要是返回了404、403、500，或者是超时了，那么SonarQube这边，都是会认为推送失败的。404这种情况，多半是地址的路径没有写对；403这种情况，经常是出在了权限，或者是Token的问题上面；500这种情况，那就要去看一看接收端那边的日志了。Webhook这件事，说到底，就是一次HTTP的调用，接收端必须得能够在合理的时间范围里面，给它返回一个成功的响应。

3、去检查一下密钥和签名

要是配置了Secret这个选项，那么接收端这边，就需要按照同一套密钥，去校验请求的内容。密钥要是对不上，接收端就有可能会把请求给拒绝掉，流水线那边，也有可能提示说签名是不匹配的。SonarQube的Webhook，它支持使用Secret去保护推送的内容，接收端这边，是需要按照事先约定好的方式，去处理签名校验的。

4、去检查一下推送的内容

Webhook所携带的负载里面，是会包含项目、分支、分析的时间、质量门禁的状态这一些信息的。接收端如果只针对某一个固定的字段做了处理，那么碰到分支扫描、多模块的项目，或者是接口的字段发生了变化的时候，解析就有可能会失败。在做排查的时候，最好是能先保存下来一份完整的请求内容，去确认一下，接收端那边，它到底是在签名、格式，还是业务处理的逻辑上面，出了问题。

三、Webhook配置后怎么稳定运行

Webhook配置成功了以后，也不是说就可以完全不再去管它了。项目的迁移、域名的变化、Jenkins的重装、代理的调整、Token的更换，这些东西，都有可能会让原来能够正常使用的Webhook，忽然之间就失效了。

1、把配置的记录保留下来

要去记录下Webhook的名称、目标的地址、它是属于哪一个项目的、接收的系统是哪一套、有没有使用Secret、是谁创建的，还有变更的时间。这样做的话，后面再碰到推送失败的时候，就不需要再跑到页面里面，去一个接一个地，猜测它们的用途了。

2、去做一次从头到尾的端到端验证

配置完成了以后，最好是能够去触发一次真实的扫描，去确认一下，SonarQube是能够把Webhook给发出去的，接收端这边，也是能够收到请求的，流水线或者是消息的平台上面，也是能够正确地展示出结果的。如果只是把配置给保存了，却不去做一次验证，就很容易到了快要发布的那个阶段，才发现质量门禁的结果，其实并没有被回传过来。

3、要定期去把那些已经没有用的Webhook给清理掉

历史项目下线了、测试的平台被废弃了、Jenkins的地址发生了变化，在这些情况发生了以后，都需要及时地去把旧的那些Webhook给清理掉。已经没有用的Webhook，会持续不断地产生失败的记录，它也会给正常的排查工作，带来干扰。全局的Webhook，尤其需要小心地去对待，因为它是有可能，会影响到好几个项目的。

总结

SonarQube Webhook应该怎样去配置，以及推送失败的时候又该怎么去排查，这两件事情，可以按照“先确认好接收的那一端，再去创建项目级或者是全局的Webhook，接着再去验证网络、地址、状态码、密钥，还有负载的内容”这样的一个顺序，来进行处理。Webhook推送失败了，通常都不是某一个孤立的原因所造成的，那些比较常见的问题，大多都集中在了服务器访问不到目标的地址、接收端那边的路径写错了、权限被拒绝了、签名没有对上，还有解析的逻辑出了毛病，这几个方面。只要把配置的记录、端到端的验证，还有失败的日志，都给保留下来，那么到了后面，质量门禁的回调，和自动的通知，才会变得更加稳定。