当前位置：首页 > 后端开发 > 正文内容

Reviewbot 开源 | 为什么咱们要打造自己的代码检查服务？

邻居的猫1个月前 (12-09)后端开发1927

Reviewbot 是七牛云开源的一个项目，旨在供给一个自保管的代码查看服务, 便利做 code review/静态查看, 以及自界说工程标准的落地。

静态查看不是个新鲜事。

我记住早在几年前，咱们就调研并运用过 sonarqube 做静态查看，但其时并没有大范围的推行。首要原因在于，一是发现的问题多数是风格问题，较少能发现缺点; 二是 sonarqube 社区版的 worker 数有约束，满意不了咱们大规模代码扫描的需求。当然，也是由于前一个问题，感觉付费并不是很合算。

而由于七牛首要运用 golang 言语，所以在静态查看方面，咱们根本运用 go vet/fmt/lint 等，再便是后来的 golangci-lint，如同也够用了。

但随着代码库房的增多，以及对工程标准的不断强化，咱们越来越发现当时的落地方法，现已开端无法满意咱们的需求。

Linter 东西的引进与更新问题

以 golangci-lint 为例，它是 go 言语 linters 聚合器，内置了 100+ linters，运用也很简略, golangci-lint run 一条指令即可。但你知道吗？假如没有特别装备，你这条指令其实只是履行其间的 6 个 linter，绝大部分 linters 都没有履行！

别的，东西本身需求更新，且许多时分咱们也会自己定制 linter 东西，这种时分该怎么做呢？假如仅有少数库房，或许还好，但假如库房许多，那保护本钱就上去了。

还有便是新事务，新库房，怎么保证相关的查看能够及时装备，相关的标准能够正确落地？

靠自觉必定是不可的。

Linter 问题的发现与修正状况

怎么保证发现的问题能够被及时修正？怎么让问题能更及时、更简略的被修正？

埋藏在许多 raw log 中的问题，必定是不简略被发现的，查找起来很费事，体会很差。

前史代码库房的存量问题，谁来改？改动就需求时刻，但实际上许多事务研制或许并没有动力来跟进。相同，变化总是有危险的，有些 lint 问题修正起来也并不简略，假如因修正 lint 问题而引进危险，那就因小失大了。

假如想了解当时安排内 lint 问题的散布及修正状况，又该怎么办呢？

怎么处理，方向在哪里？

不可否认，linter 问题也是问题，假如每行代码都能进行充沛的 lint 查看，那必定比不查看要强。

另一方面，安排内制定好的工程标准，落地在日常的开发流程中，那必定是期望被恪守的，这类便是强需。

所以这个工作值得做，但做的方法是值得考虑的，尤其是当咱们有更高寻求时。

参阅 CodeCov 的服务方法，以及 golangci-lint reviewdog 等东西的规划理念，咱们以为:

假如能关于新增库房、前史库房，不需求专人装备 job，就能主动收效，那必定是高雅的
假如能只针对 PR/MR 中的变化做剖析和反应，相似咱们做 Code Review 那样，那关于提 PR 的同学来讲必定是高雅的，可承受的，顺手修正的或许性极大
- 而进一步，针对 PR/MR 中触及的文件中的前史代码进行反应，在合理推进下，支撑夹藏修正，继续改善的或许性也会大大增强
Lint 东西多种多样，或许咱们自己开发出新东西时，能够较为轻松的让一切库房都主动收效，那也必定是十分赞的，否则就或许堕入东西越多担负越重的危险

根据上面的考虑，我以为咱们需求的是: 一个中心化的 Code Review/静态查看服务，它能主动承受整个安排内 PR/MR 事情，然后履行各种预界说的查看，并给与准确到变化文 �� 级的有用反应。它要能作为代码门禁，继续的保证入库代码质量。

而 Reviewbot 便是这样一个项目。

Reviewbot 在规划和完成上有哪些特色？

面向改善的反应方法

这将是 Reviewbot 反应问题的中心方法，它会尽或许充沛利用各 Git 渠道的本身才能，准确到变化的代码行，供给最佳的反应体会。

Github Check Run (Annotations)
Github Pull Request Review (Comments)

支撑多种 Runner

Reviewbot 是自保管的服务，引荐咱们在企业界自行布置，这样对私有代码更友爱。

Reviewbot 本身更像个办理服务，不约束布置方法。而关于使命的履行，它支撑多种 Runner，以满意不同的需求。比方:

不同的库房和 linter 东西，或许需求不同的根底环境，这时分你就能够将相关的环境做成 docker 镜像，直接经过 docker 来履行
而当使命较多时，为了履行功率，也能够挑选经过 kubernetes 集群来履行使命。

运用也很简略，在装备文件中的方针库房指定即可。相似:

dockerAsRunner:
  image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"

kubernetesAsRunner:
  image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.23.2-gocilint.1.61.0"
  namespace: "reviewbot"

零装备+定制化

本质上，Reviewbot 也是个 webhook 服务，所以咱们只需求在 git provider 渠道装备好 Reviewbot 的回调地址即可(github 也能够是 Github App)。

绝大部分的 linter 的默许最佳履行姿态都现已固定到代码中，如无特别，不需求额定装备就能对一切库房收效。

而假如库房需求特别对待，那就能够经过装备来调整。

相似:

org/repo:
  linters:
    golangci-lint:
      enable: true
      dockerAsRunner:
        image: "aslan-spock-register.qiniu.io/reviewbot/base:go1.22.3-gocilint.1.59.1"
      command:
        - "/bin/sh"
        - "-c"
        - "--"
      args:
        - |
          source env.sh
          export GO111MODULE=auto
          go mod tidy
          golangci-lint run --timeout=10m0s --allow-parallel-runners=true --print-issued-lines=false --out-format=line-number >> $ARTIFACT/lint.log 2>&1

可调查

Reviewbot 是在对工程标准强办理的布景下发生的，那作为工程标准的推进方，咱们天然有需求想了解安排内当时标准的履行状况。比方, 都有哪些问题被检出？哪些库房的问题最多？哪些库房需求特别装备？

现在 Reviewbot 支撑经过企业微信来接纳告诉，比方: