要是创建MR/PR后它能自己创建一份预览环境就好了

已于 2023-04-14 14:37:30 修改
阅读量264 收藏
点赞数
文章标签： 前端 node.js react
于 2023-04-12 10:17:57 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/bu_leng/article/details/130090947
版权
文章讲述了为了解决前端代码预览和复审过程中的不便，作者利用GitLab的Webhook和自建服务实现了自动化预览环境。通过评论触发命令，服务监听并根据命令创建、更新或删除预览环境，提高了代码审查效率，减少了手动操作。技术栈包括KoaJs、React和Vite。
摘要由CSDN通过智能技术生成

懒也是人类进步的阶梯
一个因为懒而写出来的前端工具-前端项目预览🙃

前言

在正文开始之前，不得不先提一下我们公司的代码合并流程。
日常开发中，当局者迷的我们在完成一个需求的时候常常会自我感叹：这段代码写的真完美（不是我）。而一些逻辑不自洽的代码或遗漏的边界问题可能就这么被忽略了过去。以至于当测试提bug的时候，我们看着自己的代码产生自我怀疑：我*，我当时为啥这么写？没道理啊… 。所以，我们需要一个代码复审者或者代码检查者这么一个角色，在我们把代码合并到master分支之前，帮我们检查一下，排除一些低级bug以及逻辑漏洞。

为了避免因未经审核的代码被合并到master分支上，相应的流程分三步：

  1. 在远程仓库创建一个新分支（分支名称可以因任务而定，一般采用feature/[任务号] 或fixbug/[任务号] 等）,将我们的代码提交到这个新分支上。
  2. 创建一个merge request(pr) 并指定复审者。
  3. 复审者检查后，由复审者决定是要把代码合并到master上。

看起来没什么大问题，复审者的存在保证了代码的质量。能提前排除一些逻辑漏洞或潜在问题。但是对于前端来讲，由于css不正交的特性或者复审者对于该部分功能未必有一个完整的理解，有些时候，如果不打开一份该次变更之后的环境真的不能确认变更的结果。那么，不可避免的，复审者需要增加额外的一些操作：

  1. 将当前分支的代码 clone 到本地。
  2. 切换至当前分支。
  3. yarn start，等待环境创建并查看。
  4. 查看没问题后在切换回自己的分支。

虽然不算麻烦，可以忍，但我懒啊，于是，复审同事代码一个月后的我跟组长说出了标题那一段话。不出意外的，组长完美的发挥出“谁提出的问题，就由谁来解决”的陋习 优良传统，这个任务就落到了我的头上。

💡 css的不正交：你无法只看一个属性就知道这个属性对应的效果，你必须结合另一个或多个属性一起来看

正文

还是先看效果吧

  • help指令
    在这里插入图片描述

  • create指令
    在这里插入图片描述
    在这里插入图片描述

  • delete指令
    在这里插入图片描述

因为不是每个mr都需要一份预览环境，所以没有打算在GitLab的pipeline中部署。在和组长讨论了半下午后，最后决定使用GitLab的webhook与服务进行交互。并罗列了一些需求以及实现方式。

💡 GitLab/GitHub都提供了webhook功能，如果你需要的话，它可以监听你所在项目的工作，并向你的服务器发送请求。

方案

搭建一个服务，通过GitLab的webhook，监听MR的评论和状态，并进行相应处理。

技术栈

后端：KoaJs(2.0+) + TypeScript

前端：React + TypeScript + Vite

需求

  • 通过在已创建的mr中评论的方式，与服务进行交互，并支持四个命令help 、create 、update 和delete：
    在这里插入图片描述

  • MR被合并/关闭后，应自动删除当前MR可能创建的预览环境。

  • 收到创建、更新、删除环境命令时应有实时反馈，告知用户结果（不管成功还是失败）。

  • 项目具有完整的日志系统，以及错误处理机制。

  • 服务崩溃的时候期望能收到邮件通知。

  • 提供一个前端可视化页面，用于展示所有已创建的环境，并支持手动更新和删除。

思路

有了思路才好实现，先理一下主流程的大致思路：

  1. 在GitLab创建webhook，监听项目的评论和MR变化。
  2. 在GitLab中设置访问token并设置相关权限，通过这个token，在服务中调用GitLab API，对项目进行相关操作。
  3. 在服务中注册路由，用于接收GitLab传递过来的信息。
  4. 解析GitLab传递过来的信息，得到项目名称 、MR源分支、相关命令 等信息。
  5. 利用机器人的GitLab权限，在服务中拉取远程代码，并使用Vite抛出的****createServer** API，搭建/更新环境。并在搭建成功/失败后。调用GitLab API在当前MR创建一个评论进行反馈
  6. MR合并时干掉这个环境。

实现

第一步：首先我们需要配置一下项目的webhook

project -> settings -> webhook

在这里插入图片描述

GitLab注册了13个事件。不过我们只需要关注他的comment event和Merge Request events 就够了。指定好服务的url，选完点击创建后，每当项目创建了MR，或新增了评论。GitLab就会向指定的url发送请求，并带上相关的信息。

第二步：创建访问token

project -> settings -> Access Tokens
在这里插入图片描述

给他起个名字，并赋予相应权限。点击创建后会得到一个token，把这个token保存起来，用于之后在服务中调用GitLab API。

第三步：在服务中注册路由，用于接收GitLab传递过来的信息。

import Router from 'koa-router';
const router = new Router();

router.post('/webhook', (ctx, next) => {
  const body = getRequestBody(ctx, ProjectType.Umc);
  logger.info('GitLab event: ', body.object_kind);
  handleEvents(ProjectType.Umc, body);
  ctx.status = 200;
  next();
});
export default router;

可以根据body.object_kind得知此时触发的是MR事件还是Comment事件，并作出相对应的处理。

第四步：解析gitlab传递过来的信息，得到项目名称 、MR源分支、相关命令 等信息。

// 处理MR变化
const changes = ['updated_at', 'merge_status'];
const handleMergeRequestChange = (payload: IMergeRequestParams) => {
	//获取项目id，mr描述，mrid，mr状态，源分支，mr变化信息。
	const projectId = payload.project.id;
  const { description, iid, state, source_branch } = payload.object_attributes;
  const changeItems = Object.keys(payload.changes);

	// 提取mr描述中的命令，只支持create命令
  const commandInfo = getParamsByDesc(description);

  let commentCtx = '';
  if (commandInfo?.error) {
    commentCtx = commandInfo.error;
  } else if (
    commandInfo?.command &&
    commandInfo.command !== CommandEnum.create
  ) {
    commentCtx = ':octocat: 命令无效，创建merge request时只支持create命令';
  }
  // 命令出错时的处理，调用GitLab API，在当前mr新增一个评论
  if (commentCtx) {
    GitlabService.updateComment(projectId, iid, commentCtx);
    return;
  }
	
  // 根据MR的状态决定是否创建/更新 或删除环境。
  switch (state) {
    case 'opened':
      if (!commandInfo) return;
      // 不是commit变更触发的merge event 不需要更新环境
      if (changeItems.length !== 1 || !changes.includes(changeItems[0])) {
        logger.info(`[mr: ${iid}]: 无效的merge event`);
        return;
      }
      createDev(
        iid,
        source_branch,
        projectId,
        TriggerEnum.desc,
        commandInfo?.params
      );
      break;
    case 'closed':
    case 'merged':
      deleteDev(projectId, iid);
      break;
  }
};

处理comment event与MR event类似，获取我需要的信息，检查命令的合法性以及MR的状态。

// 处理comment event
const handleCommentsChange = (payload: ICommentParams) => {
  const { note } = payload.object_attributes;
  const commandInfo = getParamsByDesc(note);
  const { id: projectId } = payload.project;
  const { iid, source_branch, state } = payload.merge_request;
  if (!commandInfo) {
    return;
  }

  let commentCtx = '';
  if (commandInfo?.error) {
    commentCtx = commandInfo.error;
  } else if (state === 'closed' || state === 'merged') {
    commentCtx = ':octocat: 当前mr已关闭/已合并，不支持命令行评论';
  }
  if (commentCtx) {
    GitlabService.updateComment(projectId, iid, commentCtx);
    return;
  }

  switch (commandInfo.command) {
    case CommandEnum.help:
      devLogger.info(`接收到 help 命令, ${iid}`);
      addCommandHelpComment(projectId, iid);
      break;
    case CommandEnum.create:
      devLogger.info(`接收到 create 命令, ${iid}`);
      createDev(
        iid,
        source_branch,
        projectId,
        TriggerEnum.cmd,
        commandInfo.params
      );
      break;
    case CommandEnum.update:
      devLogger.info(`接收到 update 命令, ${iid}`);
      updateDev(iid, source_branch, projectId, commandInfo.params);
      break;
    case CommandEnum.delete:
      devLogger.info(`接收到 delete 命令, ${iid}`);
      deleteDev(projectId, iid, TriggerEnum.cmd);
      break;
    case CommandEnum.clear:
      devLogger.info(`接收到 clear 命令, ${iid}`);
      clearComments(projectId, iid);
      break;
  }
};

第五步：利用机器人的GitLab权限，在服务中拉取远程代码，并使用Vite启动环境

npm包shelljs可以让我们在node里使用一些简单的shell命令，使用它创建一个环境目录并拉取代码

// 部分代码
// 创建评论
await GitlabService.updateEnvComment(
  projectId,
  mergeRequestId,
  `:alarm_clock: 正在为你创建proxy ip为 ${proxyIP} 预览环境...。`
);

if (shell.cd(env.CODE_DIR).code !== 0) {
  throw new Error('Error: 存放代码的文件夹路径不正确');
}
if (!shell.which('git')) {
  throw new Error('Error, 没有git命令');
}
// 进入文件
if (shell.cd(`${projectName}-${mergeRequestId}`).code !== 0) {
  shell.mkdir(`${projectName}-${mergeRequestId}`);
  shell.cd(`${projectName}-${mergeRequestId}`);
}
// 根据分支克隆代码、yarn install
await execPromise(`git clone -b ${branch} ${env.PROJECT_CLONE_ADDR}`);
logger.info(`[mr:${mergeRequestId}]:项目克隆成功`);

shell.cd(projectName);
await execPromise('yarn install');
logger.info(`[mr:${mergeRequestId}]:项目所需npm包下载成功，即将启动项目`);

//启动环境并得到预览地址，将地址告知用户
const addr = await createDevServer(projectDir, mergeRequestId, proxyIP);

logger.info(`[mr:${mergeRequestId}]: 环境启动成功: address ${addr}`);
await GitlabService.updateEnvComment(
  projectId,
  mergeRequestId,
  `:white_check_mark: 预览环境创建成功：${addr}`
);

// export const execPromise = (cmd: string) =>
//   new Promise<void>((resolve, reject) => {
//     shell.exec(cmd, (code, _, stderr) => {
//       if (code === 0) {
//         resolve();
//       } else {
//         logger.error(`error cmd: ${cmd}`);
//         reject(stderr);
//       }
//     });
//   });

Vite提供了 createServer API ，用于创建预览环境，我们可以通过这个API来启动clone的项目。不过要记得开一个子进程，在子进程里创建环境。因为Vite只提供了关闭环境的API，没有提供销毁环境的API。环境虽然关闭了，但他还在占用内存，过一段时间，服务就会因为内存溢出而挂掉（这bug让我一顿好修）。在子进程里创建环境，这样删环境的时候只需要把子进程kill掉就可以了。

//createDevServer
import { createServer } from 'vite';

const server = await createServer(env.getViteConfig(projectPath, proxyIP));
await server.listen();
const network = server.resolvedUrls?.network ?? [];
process.send?.(network[0]);

第六步：MR合并时干掉这个环境。

把子进程的pid存下来，注册一个监听事件，在MR合并的时候把进程kill掉

其他

  • GitLab SDK@gitbeaker/node ，封装了GitLab的相关API。可以省去我们自己封装API的时间。
  • 前端有个预览环境的列表和一些MR信息，由于内容不多，所以保存在了json文件里。然后写几个请求，返回一个预览环境列表。
  • 使用log4js 对项目进行日志管理，默认一个文件存储15天的信息。并且为了方便在故障的时候查看日志，还在前端加了个日志展示页面。（虽然样式有点粗糙，但是日志嘛，能看就行🙃）

end.

肆码难椎
关注
在Linux下用mkdir命令来创建目录和子目录
计算机毕业论文源码，学生个人网页制作html源码。贴近用户做网络推广和互联网优化。
08-09 2898
　　在了解用 ls 命令在目录中列出条目后，现在我们要学习在 Linux 系统下创建目录。在 Linux 下，我们可以使用 mkdir 命令。Mkdir 是“make directory” 的缩写词。在Linux下用mkdir命令来创建目录和子目录如下： 　　Mkdir 是一个用来在 Linux 系统下创建目录的命令。此命令属于内建命令。 　　你可以在你的控制台直接键入 mkdir 来使用它。 　　$ mkdir 　　默认情况下，不带任何参数运行 mkdir 命令会在当前目录下创建目录。下面是参考示
【VS Code插件开发】入门篇（一）
热门推荐
编码世界
07-31 7万+
讲解了VS Code插件入门开发，讲解了项目的搭建、测试、打包、发布等一系列流程
RTP协议入门基础
crl6的博客
04-05 1102
RTP协议入门基础 （一）RTP身世： 实时传输协议RTP（Real-time Transport Protocol）是一个网络传输协议，它作为因特网标准在 [ RFC 3550 ] 有详细说明。 RTP协议规定了互联网上传递音频和视频的标准数据包格式，可用于多播协议，单播应用中。RTP协议常用于流媒体系统（配合RTSP协议）和RTCP一起使用，它是建立在用户...
Jenkins+使用gitlab的api，新建提交合并分支，语言shell
十个菜
04-21 847
Jenkins 环境docker化 版本2..263.4 gitlab 环境docker化 版本13..7 api v4 原因：说要按分支 按流程 合并 发版，python3 也有一堆api 测了下一堆报错就不多说了 1gitlab配置令牌，不多说了给个api权限，百度一大堆 2 配置到环境变量 /etc/profile.d/gitlab_api.sh export GITLAB_URL=http://你的URL前缀没有尾斜杠 export GITLAB_API_URL=${GIT
GitLab从入门到精通超详细教程【七】
GitLab 中国发行版
03-28 722
极狐GitLab 新手指南。
基于gitlab适用于版本发布的git-flow团队开发协作规范
BASK2311的博客
02-14 242
作者：austin流川枫链接：https://juejin.cn/post/7199192593279991867。
PR 和 MR 的关联
Lucky小黄人的博客
02-02 5745
先说结论 PR(Pull Request) 和 MR(Merge Request) 两个术语想表达的意思是一模一样的，只是在不同平台的叫法不一样。PR(Pull Request)是 github 发起合并分支请求时的叫法，MR(Merge Request) 是 gitlab 发起合并分支请求时的叫法，一般在 github 会说 "提个 PR "，在 gitlab 会说 "提个 MR "。 下面是...
git pr/mr 提交规范
我的博客
01-09 1万+
说在前面 我们希望每个 mr 尽量⽐较单⼀，不要涉及太多复合的内容。这样便于 review，必要时也便于回滚。 这⾥定义了 mr 提交时，title 和 message 的⼀个规范，如果可以的话，最好每个 commit 都遵循这个规范。 定义规范的好处是： 提供更多的信息，⽅便排查与回滚; 过滤关键字，迅速定位. mr title 的规范 形式化定义： <type>(<scope>): <subject> 其中，各个域的说明如下： type：⽤于说明这次 mr/
VR/ AR/ MR/ CR/ XR/ AV的区别及简介
hairuiJY
07-12 1万+
VR  Virtual Reality，虚拟现实，算是这块地头的老大哥了，长兄如父，之后的相关概念，也大都是基于VR衍生出来的。 官方一点的说法是，VR技术是一种可以创建和体验虚拟世界的计算机仿真系统，它利用计算机生成一种模拟环境，是一种多源信息融合的、交互式的、三维动态视景和实体行为的系统仿真，该系统仿真可以使用户沉浸到设定的虚拟环境中。 这么一大段，其实有用的也就一个词——体
Android 创建文件夹 && 创建文件 （写人数据 || 续写数据）
Mr_ChenXu的博客
01-19 7711
记录自己比较头痛老忘记的方法，创建文件夹，存放文件，存放图片等资源，这样可以再开发APP时从本地加载，减少网络请求，无网络请求也可以完成基本使用。 需要读写权限：（*6.0以上需要动态加载权限） uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> uses-permission
gitbeaker：:robot_face:全面支持所有Gitlab API服务的GitLab API NodeJS库
02-03
:robot_face: API NodeJS库完全支持所有服务。 目录 安装 # Install from npm npm install @gitbeaker/node # NodeJS default, index.es.js for esm npm install @gitbeaker/browser # UMD default npm install @gitbeaker/cli # CLI 入门 节点JS // ES6 (>=node 10.16.0 LTS) import { Gitlab } from '@gitbeaker/node' ; // All Resources import { Projects } from '@gitbeaker/node' ; // Just the Project Resource //...etc // ES5, assuming native or polyfilled Promise is available const { Gitlab } = require ( '@gitbeaker/node' ) ; 浏览器
Git协同开发解决冲突与Pr、Mr及路飞项目主页搭建
主要发布一些日常学习代码及理解
11-09 1667
想写介绍了协同开发的整体流程，以及多人同一分支开发冲突的解决方法，线上分支合并PrMr 路飞项目前端主页搭建
Github或Gitlab等申请PR或MR（pull request & merge request）的时候如果不能自动合并代码发生冲突了要怎么办
w8y56f的专栏
09-06 4921
最初dev在c3，feat在c5，从dev拉出dev_tmp肯定也在c3（左图），此时feat合并到dev_tmp，dev_tmp前进到c6二dev和feat不动（右图），此时。之所以不太建议，是因为你在网页上操作，简单的还好，文件一多，依赖关系复杂，就会出现改错，还是老实到IDEA里处理好冲突之后再提PR吧。上面的图中，中间的图执行feat合并到dev，或者右边的图执行dev合并到feat，都会得到如下的结果，即dev和feat都指向c6。在Github中申请PR，请求a合并到b，有时候没冲突，好办。
三大巨头逐鹿代码审查战场：GitHub PR、GitLab MR与Bitbucket Code Insights，谁主沉浮？
最新发布
java专栏
06-17 1080
GitHub Pull Request、GitLab Merge Request和Bitbucket Code Insights各有千秋，分别在代码审查、CI/CD集成和代码质量洞察方面提供强大的支持。选择哪个工具取决于团队的具体需求、现有的开发流程以及对集成平台的偏好。无论哪种工具，它们都是提升代码质量和团队协作效率的得力助手。
MR 运行原理
qq_36864672的博客
11-17 1万+
1、Map-Reduce的逻辑过程 假设我们需要处理一批有关天气的数据，其格式如下： 按照ASCII码存储，每行一条记录每一行字符从0开始计数，第15个到第18个字符为年第25个到第29个字符为温度，其中第25位是符号+/- 0067011990999991950051507+0000+ 0043011990999991950051512+0022+
MR的搭建
千樽醉的博客
05-07 202
MR的搭建 :hadoop 2.x yarn 部署&配置: cd $HADOOP_HOME/etc/hadoop vi mapred-site.xml <property> <name>mapreduce.framework.name</name> <value>yarn</value>...
Gitlab14从搭建到落地CICD(一)
Odboy
07-12 580
前期准备 参考我的上一篇文章: Gitlab从搭建到差点放弃 # 已知路径 /usr/local/apache-maven-3.6.3 /usr/local/jdk8u262-b10 # 配置路径 cd /usr/local && ln -s ./apache-maven-3.6.3 maven3 cd /usr/local && ln -s ...
Git开发指南(涵盖GitLab的merge request(简称：mr))
Koren_Wei的博客
12-12 6363
Gitlab 配置 ssh 第0步：git pull origin master第1步：git checkout -b &lt;分支名称&gt;第2步：功能开发完成第3步：git status第4步：git add .第5步：git commit -m ‘修改信息’第6步：git pull origin master第7步：处理冲突第8步：git push origin yourBranch第9步...
gitlab 删除分支_初识gitlab工作流
weixin_39654322的博客
11-30 372
git对我来说挺难理解的，平时遇到问题也是绕着走，倒也没啥大问题，但基于git软件的工作流却很重要，尤其对于一个组织来说。git工作流、github工作流、gitlab工作流都属于特性分支(feature branches)的类别，今天主要理解gitlab工作流，它结合了特性驱动开发、特性分支、issuse跟踪。1：git工作流的问题git工作流比较古老，最大的问题是太复杂，它包含mas...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值