确定还不来看看?这样管理你的代码库既方便又省心!
又双叒叕搞事情了!
这次,建木 CI 准备通过流程化的方式对代码库中的代码进行统一管理。听了是不是有点小激动?确实,现在像这些非业务相关的东西都可以交给建木 CI 去做了,这样势必会为我们减少不少的开发工作量。闲话少说,接着就让我们一起来看看,如何搭配建木 CI 去实现这一功能吧!
在正式介绍之前,希望大家能够耐心将下面两个问题看完,这或许能让你对流程有个更好的理解!
通过何种方式管理代码库?
用建木 CI 写过流程的小伙伴应该清楚,我们在编写项目时是可以为项目添加流程触发器 webhook 的,如果对这个点不太清楚,可以点击触发器对应学习一下。为代码仓库配置了 webhook 的好处在于,今后做类似 Push、Pull Request 、新建 issue 等操作时,git 代码托管平台就会通过这个 webhook 地址向该项目发送对应请求。这样,利用这些“钩子”,在流程中我们就能非常方便地对代码库进行管理了。
哪些场景下需要触发流程对代码库进行管理?
这个问题其实没有一个确切的回答,因为什么场景下触发哪些流程取决于使用者的实际需求。这里我们以在 gitee 平台上管理代码为例,在 gitee 的 webhooks 页面中可以看到,它可以在 Push、Tag Push、Issue、Pull Request、评论这 5 个事件下对 webhook 地址发送请求。因此,我们可以利用不同的“钩子”,来实现不同情况下对代码库的管理。
看完上述两个问题后,相信大家心中的疑虑也已经少了很多。但是,这时肯定又有小伙伴心想:一共就两个问题,最后一个还没有答案,这不玩我吗?具体怎么选也没讲,无非还要自己去趟浑水过河?一整个直接无语有没有😓。哈哈哈别急,这里的浑水建木早已经替大家趟过了。如果不涉及特殊的需求,大家步调一致跟着走就行。综合实际项目的开发过程来看,其实多数情况下,我们只需涉及到如下三个场景,就可以达到管理代码库的需求。
场景一 :push 代码到仓库主分支
首先在 gitee 上创建一个名为 code-repository-manage 的仓库
将该仓库交给建木 CI 管理
拷贝流程DSL,在建木 CI 上新建项目
复制项目 webhook 链接,在 gitee 仓库下进行配置
流程演示
将新建的仓库代码克隆到本地
新增一个 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。
本文为建木博主「comyan」的原创投稿文章,转载请联系授权。
评论