Reviewbot Is a seven cattle cloud open source project , aims to provide a self-hosted code review service , easy to do code review/static check , as well as custom engineering specifications of the landing .
Static checks are not a new thing.
I remember a few years ago, we investigated and used sonarqube to do static checking, but we didn't promote it widely. The main reasons are: first, most of the problems found are style issues, and fewer defects can be found; second, the number of workers in the community version of sonarqube is limited, which can't meet the needs of our large-scale code scanning. Of course, also because of the former problem, I feel that the payment is not very cost-effective.
And since Seven Bulls mainly uses the golang language, for static checking, we basically use go vet/fmt/lint, etc., and then later golangci-lint, which seems to be good enough.
However, with the proliferation of code repositories and the ever-increasing reinforcement of engineering specifications, it became increasingly clear that the current way of landing a project was beginning to fall short of meeting our needs.
Issues with the introduction and updating of the Linter tool
Take golangci-lint for example, it's a go language linters aggregator with 100+ linters built-in, and it's very simple to use, withgolangci-lint run A single command will do. But you know what? Without any special configuration, your command actually only executes 6 of the linter, and most of the linters are not executed!
Also, the tools themselves need to be updated, and in many cases we customize the linter tools ourselves, so what do we do when that happens? If there are only a few repositories, it may be fine, but if there are a lot of repositories, then the maintenance cost goes up.
And then there is the new business, the new warehouse, how to ensure that the relevant checks can be configured in a timely manner, and the relevant specifications can be correctly landed?
It must not be possible to rely on self-consciousness.
Status of Linter problem discovery and fixes
How do you ensure that problems you find can be fixed in a timely manner? How can we make it easier to fix problems in a more timely manner?
Problems buried in large amounts of raw logs must not be easy to find, are a pain in the ass to locate, and are a poor experience.
Who is going to change the stock issues of historical code repositories? Changes take time, but in reality many business developers may not have the incentive to follow through. Similarly, change is always risky, and some lint issues are not easy to fix, so if you introduce risk by fixing a lint issue, it's not worth it.
What if you want to understand the current distribution of lint issues and fixes within your organization?
How can it be solved and where is the direction?
Admittedly, lint problems are problems too, and if every line of code is fully lint-checked, that must be better than no checking at all.
On the other hand, a well established engineering specification within the organization, landed in the day-to-day development process, that must be expected to be adhered to, and this type is a strong need.
So this is something worth doing, but the way it's done is something to think about, especially if we have higher aspirations.
consultationCodeCov the way in which the service is provided, andgolangci-lint reviewdog The design philosophy of tools such as we believe that.
- It would be elegant if we could automate the process of adding new repositories and historical repositories without having to configure a job.
- If we can only analyze and provide feedback on changes in PR/MR, similar to what we do in Code Review, then it will be elegant and acceptable to the people who bring up PR, and the possibility of fixing it on the fly is very high.
- And further, the possibility of continuous improvement is greatly enhanced by feedback against historical code in documents covered in PR/MR, with a reasonable push to support entrainment of changes
- It would be great to have a variety of Lint tools, or to be able to automate all the repositories more easily when we develop new tools ourselves, otherwise we run the risk of being burdened with more tools!
Based on the above reflections, here's what I think we need.A centralized Code Review/Static Inspection service that automatically accepts PR/MR events from across the organization, then performs a variety of predefined inspections and gives effective feedback down to the change text level. It should be able to act as a code gatekeeper to continuously guarantee the quality of incoming code.
(indicates contrast)Reviewbot It's just such a project.
What are the features of Reviewbot in terms of design and implementation?
Improvement-oriented feedback
This will be the core of Reviewbot's approach to feedback, and it will take full advantage of each Git platform's own capabilities as much as possible to provide the best possible feedback experience down to the line of code that has changed.
-
Github Check Run (Annotations)
-
Github Pull Request Review (Comments)
Supports multiple Runners
Reviewbot is a self-hosted service, and it is recommended that you deploy it yourself within your organization so that it is more private code friendly.
Reviewbot itself is more like a managed service, without limiting the deployment method. For task execution, it supports multiple Runners to meet different needs. For example.
- Different repositories and linter tools may require different underlying environments, which you can then make a docker image of the relevant environment and execute it directly through docker
- And when there are more tasks, you can also choose to execute them through a kubernetes cluster for execution efficiency.
It's also easy to use, just specify the target repository in the config file. Similar to.
dockerAsRunner:
image: "/reviewbot/base:go1.22.3-gocilint.1.59.1"
kubernetesAsRunner:
image: "/reviewbot/base:go1.23.2-gocilint.1.61.0"
namespace: "reviewbot"
Zero Configuration + Customization
Essentially, Reviewbot is also a webhook service, so all we need to do is configure the Reviewbot callback address in the git provider platform (github or Github App).
The default optimal execution posture for most of linter is fixed in the code and, unless otherwise specified, does not need to be configured to work for all repositories.
And if the warehouse needs special treatment, then it can be adjusted by configuration.
Similar.
org/repo:
linters:
golangci-lint:
enable: true
dockerAsRunner:
image: "/reviewbot/base:go1.22.3-gocilint.1.59.1"
command:
- "/bin/sh"
- "-c"
- "--"
args:
- |
source
export GO111MODULE=auto
go mod tidy
golangci-lint run --timeout=10m0s --allow-parallel-runners=true --print-issued-lines=false --out-format=line-number >> $ARTIFACT/ 2>&1
observable
Reviewbot was created in the context of strong management of engineering specifications, so naturally, as a promoter of engineering specifications, we have a need to understand the current status of the implementation of the specifications in our organization. For example, what issues are being detected? Which warehouses have the most problems? Which warehouses require special configurations?
Currently Reviewbot supports receiving notifications via enterprise WeChat, e.g..
- Detection of valid issues
- encounter an error
Of course, more ways may be supported in the future as well.
For other more features and poses, please refer to the repository at./qiniu/reviewbot
Future plans for Reviewbot
As an open source project, Reviewbot still needs to solve a lot of usability and ease-of-use issues to improve the user experience, such as the most typical, access to more git providers (gitlab/gitee, etc.), support for CLI mode operation.
But I personally believe that as a code review service, providing more detection capabilities is the top priority. Because this is not only the industry needs, but also our own needs.
So we will not only introduce Seven Bull's internal recommended specifications, but also research and explore more industry tools, and at the same time, we will consider the introduction of AI to explore the application of AI in code review and so on.
Anyway, Reviewbot is still very young, we are continuously improving it, and we welcome you to try it out and give us your valuable opinions. Of course, you are more than welcome to participate in the construction of the project.
Thank you all.