记GIT批量更新脚本引发的事故
< 返回列表时间: 2020-03-24来源:OSCHINA
【围观】麒麟芯片遭打压成绝版,华为亿元投入又砸向了哪里?>>>
我们产品团队内部一直有一个需求,通过脚本轮询git仓库的方式来触发流水线,开发人员也可以通过脚本轮询来更新本地的代码,十分的方便。 仓库一有变更,轮询脚本便会拉取到最新的commit来触发流水线进行编译测试构建等操作,不需要再人工进行干预。 最近比较有空,就腾出时间来写了一个简单的轮询脚本, 流程大致如下:
1: 每隔5s轮询一遍我们组织下的所有仓库状态,
2: 有新提交之后,将新的commit拉取下来,
3: 触发编译构建等后续操作
写完之后将脚本放在我们的构建机器上面去跑,开始跑着感觉效果不错,推了几次commit,构建都成功触发了。结果脚本运行没过多久,就有同事在开发群里反馈本地拉不了代码了,开始还以为是公司自建的git平台服务出问题了,立马找到git平台同事一问,才知道是我们组织每小时的下载次数超过了5000次,触发了git平台的限流,需要等一段时间才能恢复正常的下载请求。看到开发同事都在吐槽拉不了代码,立马把新脚本下了线,过了差不多半个小时之后,我们组的代码下载才恢复正常,事后找到git平台支撑人员理论: 我们组只是用脚本去轮询组织下的仓库是否有新的commit提交,当一个仓库有新的commit时才会进行下载,并不是一直在轮询下载仓库代码,为什么会触发到限流呢? git平台那边的同学给的反馈是轮询也会消耗git平台的服务器的资源,当平台总并发量特别高时,会影响到所有用户的使用,包括界面访问和本地代码都会被拖慢,所以也限制了这种情况的没小时访问次数,在交流的过程中git平台的同学也给我们提了一个很好的建议,这里记录一下,分享给大家:
git平台一般支持推送事件触发webhook回调,在仓库设置界面中可以开启这个好用的功能。 使用wehook需要先在流水线机器上运行一个服务,服务的大致逻辑如下: 主要是需要运行一个监听程序,我这里是用springboot做的,大家可以参考一下 @RequestMapping("/Callback") public class GetCahngeController { @RequestMapping("/get") public String get(HttpServletRequest request){ request.request.getParameter('after') //取到最新的commit request.request.getParameter('repository') //获取仓库相关信息 doClone() //通过获取的仓库地址和最新的分支等信息,将仓库拉取下来 doBuild() //执行后续操作 } }
服务起好之后就可以将服务的地址填到webhook设置中,然后勾选push触发,如果是触发上线发布的流程的话,可以选择tag push,就可以实现打tag之后自动发布版本了,比原先的轮询方式还要方便。
替换到webhook之后,当有新的commit push到仓库时,webhook就会发一条消息到这个服务上来,消息中会包含提交人,commit推往的分支,最新的commit的信息和commit的父节点的信息,还会返回仓库的详细信息,如clone地址等,可以通过这个clone地址可commit id结合起来,取到最新的一次提交,然后发起构建,比轮询的实时性更高,而且不用当心轮询导致仓库的下载次数超限,影响公司的git服务。
如果你要是觉得组织下仓库太多设置webhook不方便的话,可以使用webhook相关的设置api,批量给仓库设置webhook。
在这里给大家分享一下,希望这个方法能对大家有帮助。
热门排行