我建造的

我构建了一个github工作流程，该工作流可以使用项目的.eslintrc.json文件中设置的规则来检查每个拉的请求，并检查错误。这对于维护人员的贡献者可能不会遵循项目设置的规则，这可能会导致杂乱的代码库，这对于维护者的规模可能很难。

类别提交：维护者必备

应用链接

Github repository

描述

name: eslinter

on:
  pull_request:
    branches:
      - "**"
    types: [opened]

jobs:
  linter:
    name: eslint runner
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v2
      - uses: reviewdog/action-eslint@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          reporter: github-pr-review
          eslint_flags: "src/"

这是简单的工作流程。 eslint_flags:可以更改为所需的特定目录。

链接到源代码

Github Repo

允许许可证

什么

背景（是什么让您决定构建这个特定的应用程序？是什么启发了您？）

在没有某人使用ESLINT的团队项目上工作可能会使整个项目变得混乱。实施此操作将使维护者的生活更加轻松，因为他们可以放心，不会将未打入的代码推到代码库中。

我是如何构建它的（您是如何利用GitHub Action或Github代码？

我终于制作了一个CI工具，对人们有帮助。对我来说，这无疑是第一个。我为GitHub Actions和reviewdog提供了官方文档的帮助，并在几个小时内将其煮熟，因为我只知道最后一天的黑客马拉松。非常感谢Reviewdog的令人敬畏的动作！
测试每次破裂时，新PRS都是一个问题。我希望将来会有一种脱机测试的方法。

其他资源/信息

• reviewdog