确定还不来看看?这样管理你的代码库既方便又省心!
2022-04-19 comyan
确定还不来看看?这样管理你的代码库既方便又省心!
作者:comyan 发布时间:2022-04-19 10:00:00

又双叒叕搞事情了!

这次,建木CI准备通过流程化的方式对代码库中的代码进行统一管理。听了是不是有点小激动?确实,现在像这些非业务相关的东西都可以交给建木CI去做了,这样势必会为我们减少不少的开发工作量。闲话少说,接着就让我们一起来看看,如何搭配建木CI去实现这一功能吧!

在正式介绍之前,希望大家能够耐心将下面两个问题看完,这或许能让你对流程有个更好的理解!

通过何种方式管理代码库?

用建木CI写过流程的小伙伴应该清楚,我们在编写项目时是可以为项目添加流程触发器webhook的,如果对这个点不太清楚,可以点击触发器对应学习一下。为代码仓库配置了webhook的好处在于,今后做类似Push、Pull Request 、新建issue等操作时,git代码托管平台就会通过这个webhook地址向该项目发送对应请求。这样,利用这些“钩子”,在流程中我们就能非常方便地对代码库进行管理了。

哪些场景下需要触发流程对代码库进行管理?

这个问题其实没有一个确切的回答,因为什么场景下触发哪些流程取决于使用者的实际需求。这里我们以在gitee平台上管理代码为例,在gitee的webhooks页面中可以看到,它可以在Push、Tag Push、Issue、Pull Request、评论这5个事件下对webhook地址发送请求。因此,我们可以利用不同的“钩子”,来实现不同情况下对代码库的管理。

看完上述两个问题后,相信大家心中的疑虑也已经少了很多。但是,这时肯定又有小伙伴心想:一共就两个问题,最后一个还没有答案,这不玩我吗?具体怎么选也没讲,无非还要自己去趟浑水过河?一整个直接无语有没有😓。哈哈哈别急,这里的浑水建木早已经替大家趟过了。如果不涉及特殊的需求,大家步调一致跟着走就行。综合实际项目的开发过程来看,其实多数情况下,我们只需涉及到如下三个场景,就可以达到管理代码库的需求。

场景一 :push代码到仓库主分支

  1. 首先在gitee上创建一个名为code-repository-manage的仓库

  1. 将该仓库交给建木CI管理
  • 拷贝流程DSL,在建木CI上新建项目
  • 复制项目webhook链接,在gitee仓库下进行配置

  1. 流程演示
  • 将新建的仓库代码克隆到本地
  • 新增一个peizhi.js文件(文件名字可自定义),用于指定该仓库中前端代码按照何种规则进行格式化,具体格式化配置文件命名规则以及配置项可自行参考prettier进行查阅
  • 新增test.vue文件
  • 将新增的代码推送到仓库主分支,自动触发流程执行

  • 查看流程的执行过程

  • 流程执行成功,代码被格式化

新增了一条自动格式化的commit信息

查看此次提交文件的变动情况,发现test.vue文件被自动格式化了

场景二:同仓库的不同分支间创建PR

  • 仓库下新建其他分支comyan
  • comyan分支下新建一个test.js文件

  • 提交代码到comyan分支,comyan分支—>master分支创建PR

管理代码库流程被触发

查看提交记录,test.js已被格式化

场景三:fork他人仓库后创建PR

将仓库fork一份,在fork仓库下新建PR

  • 在fork仓库下对test.vue文件再次进行修改

  • 新建PR,触发流程

注意⚠️:fork仓库下提交PR,触发流程后只会指定PR审查人和更新该仓库下的最少审查人数,不会进行代码格式化。格式化操作需等到审查人将PR合并后,gitee会自动把合并后的代码push到目标分支,从而又进入第一个场景。之所以采用这种机制,是因为流程DSL中没有对fork的仓库有push代码的权限。

PR合并后流程再次被触发

test.vue文件被格式化

这里结合前几次分享的前端代码格式化流程,给大家进行了一个知识点的串联。代码的格式化其实也属于对代码库中代码的管理,因此串连在管理代码库流程中非常有必要。同时,依赖于上面三个场景,我们还能在此基础上进行更多拓展,例如:代码review、eslint代码检测。

文章到这儿就结束了,如需了解流程具体实现,请参考流程DSL