github 自动生成代码_如何在Github上自动执行代码评论

github 自动生成代码

by Mukesh Thawani

由Mukesh Thawani

如何在Github上自动执行代码评论 (How to automate Code Reviews on Github)

Creating pull requests and reviewing them are two of the most common tasks in a developer’s daily schedule. Most projects have common guidelines which developers need to follow while creating and reviewing the pull requests.

创建拉取请求并进行审查是开发人员日常工作中最常见的两个任务。 大多数项目都有共同的准则，开发人员在创建和查看拉取请求时需要遵循这些准则。

Now, it is hard for developers to remember every guideline while making a pull request. It is even more difficult for reviewers to ensure that every line of code is compliant to the set guidelines.

现在，开发人员在发出拉取请求时很难记住每条准则。 对于审阅者而言，要确保每行代码都符合所设定的准则甚至更加困难。

We faced the same problem with our projects and solved it by automating the major part of the manual rote work. This made the lives of our developers and reviewers a lot easier. They spent more time improving code quality and less on common chores.

我们的项目也遇到了同样的问题，并通过使手工死记硬背的工作自动化来解决了这个问题。 这使我们的开发人员和审阅者的生活变得更加轻松。 他们花费更多的时间来提高代码质量，而花更少的时间处理常见的琐事。

In this article, I will describe exactly how we did it, what all aspects of the process we automated and the tools we used for this.

在本文中，我将确切描述我们是如何做到的，自动化过程的各个方面以及用于此目的的工具。

自动化样式问题 (Automate styling issues)

We don’t want our reviewers asking the contributors to add the corresponding Jira issue number and description whenever they make a pull request. Instead, we have deployed a bot that does all the regular checks. This helps contributors to follow project guidelines.

我们不希望我们的审稿人要求贡献者在提出拉取请求时添加相应的Jira问题编号和描述。 相反，我们部署了执行所有常规检查的漫游器。 这有助于贡献者遵循项目准则。

Yes, a bot can verify if the description is present or not by checking the body of the pull request. It can comment on a pull request if the description is missing.

是的，机器人可以通过检查拉取请求的正文来验证描述是否存在。 如果缺少描述，它可以对请求请求发表评论。

We can also add a pull request template to get some of the information related to the pull request. But this approach increases the friction required to create a pull request. When we add rules, we need to make sure that the experience of a new developer will be as frictionless as possible. At the same time, we need to maintain the code quality.

我们还可以添加一个请求请求模板，以获取一些与请求请求有关的信息。 但是这种方法增加了创建拉取请求所需的摩擦。 当添加规则时，我们需要确保新开发者的经验将尽可能保持摩擦。 同时，我们需要保持代码质量。

Now let’s look at the steps required in creating such a bot.

现在，让我们看一下创建这种机器人所需的步骤。

救援的“危险” (‘Danger’ to the rescue)

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review.

危险 在您的CI流程中运行，使团队有机会自动执行常见的代码审查琐事。 这提供了构建中的另一个逻辑步骤，通过此Danger可以帮助减少日常代码检查中的死记硬背任务。

You can use Danger to codify your team’s norms. Leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review.

您可以使用“危险”来整理团队的规范。 让人们去思考更棘手的问题。 她通过根据您使用Ruby脚本语言创建的规则将消息保留在PR中来实现此目的。 随着时间的流逝，遵循规则，消息会进行修改以反映代码审查的当前状态。

Danger is used in all sorts of projects: ruby gems, python apps, Xcode projects, blogs, npm websites and modules.

危险用于各种项目：ruby gems，python应用程序，Xcode项目，博客，npm网站和模块。

It will give you an abstraction on top of Github’s API to get details related to a pull request and perform the necessary checks. It is created and maintained by Orta and many other awesome contributors. After installation, you need to create a file named Dangerfile which will contain all the rules. This file should be present in the root of your project.

它将为您提供基于Github API的抽象，以获取与拉取请求相关的详细信息并执行必要的检查。 它是由Orta和许多其他杰出贡献者创建和维护的。 安装后，您需要创建一个名为Dangerfile的文件，其中将包含所有规则。 该文件应存在于项目的根目录中。

After adding this file you are all set with the rules. Now you need to run Danger every time someone creates a pull request.

添加此文件后，您便已准备好所有规则。 现在，每次有人创建拉取请求时，您都需要运行Danger。

将其添加到您的CI工作流程 (Adding it to your CI workflow)

We use Bitrise in our mobile SDK projects. It’s a Continuous Integration and Continuous Delivery service for mobile Apps. If you are using a different CI service then, you can check this guide on how you can integrate Danger with that service. There is a detailed blog post on integrating Danger with Bitrise. I will summarise it in five points:

我们在移动SDK项目中使用Bitrise。 这是针对移动应用程序的持续集成和持续交付服务。 如果您使用其他CI服务，则可以查看本指南 ，了解如何将Danger与该服务集成。 关于将Danger与Bitrise集成在一起的详细博客文章 。 我将总结五点：

• Install bundler, create a Gemfile and add the Danger gem to the Gemfile.
  安装捆绑程序，创建一个Gemfile并将Danger gem添加到Gemfile中。
• Create a Dangerfile for your project.
  为您的项目创建一个Dangerfile。
• Create a bot user on Github and a Personal Access Token for the bot.
  在Github上创建机器人用户，并为该机器人创建个人访问令牌。
• Then add the generated token on Bitrise.
  然后在Bitrise上添加生成的令牌。
• Add a script step in the project’s workflow. That’s it! ?
  在项目的工作流程中添加脚本步骤。 而已！ ？

我们可以自动化的规则 (Rules which we can Automate)

One of the ways to identify what rules we can automate is by looking at Github’s pull request API response. By comparing the API response with our pull request checklist or guideline, we can get an idea of the possibilities that are there. This is how the response looks like:

识别我们可以自动化的规则的一种方法是查看Github的请求请求API响应。 通过将API响应与我们的请求请求清单或指南进行比较，我们可以了解那里的可能性。 这是响应的样子：

• It returns almost all the information you see on GitHub’s pull request webpage like title, description, assignee, reviewers, labels etc.
  它返回您在GitHub的拉取请求网页上看到的几乎所有信息，例如标题，描述，受让人，审阅者，标签等。
• There’s one more API to fetch a list of changed files. For each file, it will return the name of the file, the number of additions to the file, the number of deletions to the file.
  还有一个API可以获取已更改文件的列表。 对于每个文件，它将返回文件的名称，文件的添加数量，文件的删除数量。
• We don’t have to use this APIs as we will be using Danger which gives us an easy way to interact with this data.
  我们不必使用此API，因为我们将使用Danger，它使我们能够轻松地与这些数据进行交互。

我们自动化的规则清单 (List of Rules we Automated)

When we were adding Danger to our repository we looked at our requirements and some of the other projects which were using Danger. Below are some of the checks that we have in our projects.

当我们将Danger添加到存储库时，我们查看了需求以及其他一些使用Danger的项目。 以下是我们在项目中进行的一些检查 。

• Warn if it’s a big PR: We tend to make this mistake of pushing a lot of changes in one PR. Reviewing such PRs is a difficult task. We added a warning which shows up when the number of lines updated in a PR is more than 500.

  如果PR很大 ，请发出警告 ：我们往往会犯这样一个错误：在一个PR中进行大量更改。 审查此类PR是一项艰巨的任务。 我们添加了一条警告，该警告在PR中更新的行数超过500时显示。

• Encourage pull request descriptions: Sometimes developers think that description is not necessary or we forget to add. Even though you mentioned the issue number, a brief description always helps and gives a context to the pull request. To see if the description is empty or not we can check the body length:

  鼓励请求请求描述 ：有时开发人员认为描述是不必要的，或者我们忘记添加。 即使您提到了问题编号，简短的描述也总是有帮助的，并为拉取请求提供了上下文。 要查看描述是否为空，我们可以检查主体长度：

• Check if the tests are missing: We all know tests are important and yet we tend to skip this step. Whenever we do any modification in the source code, we should add tests if possible. So, now it warns if there are any changes in the source code and the tests folder is not modified, which means new tests are missing.

  检查是否缺少测试 ：我们都知道测试很重要，但是我们倾向于跳过这一步。 每当我们在源代码中进行任何修改时，都应尽可能添加测试。 因此，现在它会警告源代码中是否有任何更改，并且tests文件夹没有被修改，这意味着缺少新的测试。

• Update Changelog: Added a new feature or fixed a bug — update the Changelog with the details. We made it mandatory to add a Changelog entry if the change is nontrivial. If the Changelog is not updated and pull request is not marked as trivial, then our CI fails the build. Now, we don’t have to keep track whether the Changelog was updated.

  更新变更日志 ：添加了新功能或修复了错误-使用详细信息更新变更日志。 如果更改不重要，则必须添加一个Changelog条目。 如果变更日志未更新，并且拉取请求未标记为琐碎，则我们的配置项将使构建失败。 现在，我们不必跟踪变更日志是否已更新。

• Encourage rebase not merge commits: As the project grows it’s always recommended that we should avoid ‘merge’ commits so that the project has a clean history. We prefer using rebase instead of merging different branches. We can add a check for messages of this format: “Merge branch ‘master’” to avoid the merge commits.

  鼓励不要重新合并提交 ：随项目的增长，始终建议我们避免“合并”提交，以便项目具有清晰的历史记录。 我们更喜欢使用rebase而不是合并不同的分支。 我们可以添加以下格式的消息检查：“ Merge branch'master'”，以避免合并提交。

下一步去哪里 (Where to go next)

For reference, you can check ApplozicSwift’s Dangerfile or in some of the other popular open source projects like React Native or CocoaPods. I discovered while writing this blog post that projects like React Native and React were also using danger. This shows us how this process of automating these checks has become part of the common pull requests workflow.

作为参考，您可以检查ApplozicSwift的Dangerfile或其他一些流行的开源项目，例如React Native或CocoaPods 。 我在撰写此博客文章时发现，像React Native和React这样的项目也在使用危险。 这向我们展示了这些自动执行这些检查的过程如何成为常见的请求请求工作流程的一部分。

Liked the story? Hit that clap button and follow me on Medium. Thanks for reading! This article was originally published on Kommunicate blog.

喜欢这个故事吗？ 点击那个拍手按钮，在Medium上跟随我。 谢谢阅读！ 本文最初发表在Kommunicate博客上 。

翻译自: https://www.freecodecamp.org/news/how-to-automate-code-reviews-on-github-41be46250712/

github 自动生成代码