如何在每次推送提交时在 GitHub 工作流程中运行 commitlint

Posted 2023-02-19

【中文标题】如何在每次推送提交时在 GitHub 工作流程中运行 commitlint

【英文标题】：How to run commitlint in GitHub workflow on every commit of a push

【发布时间】：2021-07-22 05:01:53

【问题描述】：

我有一个 Github 存储库，在本地安装了 commitlint and husky，并希望在验证拉取请求时设置一个在每次推送提交时运行 commitlint 的工作流。 在主分支上，较旧的提交不遵循传统的提交规则。

我根据这条评论创建了一个单独的分支

https://github.com/conventional-changelog/commitlint/issues/586#issuecomment-657226800

我从这个工作流程开始

name: Run commitlint on pull request

on: pull_request

jobs:
  run-commitlint-on-pull-request:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Node
        uses: actions/setup-node@v2
        with:
          node-version: 14.x

      - name: Install dependencies
        run: npm install

      - name: Validate all commits from PR
        run: npx commitlint --from HEAD~$ github.event.pull_request.commits  --to HEAD --verbose

我按照传统的提交规则又做了两次提交并开始了一个拉取请求

我预计工作流不会运行，因为我在主分支上还不存在。 实际上它运行 我希望工作流只检查 PR 提交 工作流失败，因为它开始验证主分支中的每个提交。而且由于我知道旧的提交不遵守规则，所以这永远不会通过。

我想到的第一个解决方案是重新设置所有内容并重命名每个提交以遵循规则，但这需要付出巨大的努力。

我不确定我是否必须在这里改进这一行

npx commitlint --from HEAD~$ github.event.pull_request.commits --to HEAD --verbose

仅检查来自 PR 的提交（不幸的是，我不知道那里需要修复什么）。

您有什么想法或正在重新定位和重命名唯一的解决方案？

【问题讨论】：

试试npx commitlint --from $commit --to HEAD --verbose || exit 1

抱歉，很遗憾，|| exit 1 没有帮助。工作流程仍然通过

npx commitlint 是否以错误代码退出？

抱歉，我没能找到。但是图像显示我必须修复我认为的语法？

IMO 如果你想逐个测试提交 --from $commit --to HEAD 是错误的，它应该是一个提交，类似于 --from $commit~ --to $commit。或者不是循环测试一次所有提交：--from $ github.base_ref --to $ github.head_ref without a loop。

【参考方案1】：

解决方案

直接的解决方案是将 commitlint 的 --to 和 --from 参数与 SHA-1 值 一起使用，而不是使用分支名称或相对引用.一方面，这可靠地解决了工作树中未知修订或路径的问题。另一方面，只会检查 PR 范围内的提交。作为旁注：GitHub 对正在签出的临时合并使用相同的引用 (SHA-1)。

我们需要 base-SHA 以及 head-SHA。在 GitHub 操作中，这些值在 github-context 中事件的拉取请求对象中可用。

因此，您可以使用经过测试并按预期工作的以下行：

npx commitlint --from $ github.event.pull_request.base.sha  --to $ github.event.pull_request.head.sha  --verbose

演示

这是一个POC repository on GitHub，包含 3 个测试用例（拉取请求）。

完整的工作流程

name: Run Commitlint on PR

on:
  pull_request:

jobs:

  run-commitlint-on-pr:
    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Node
        uses: actions/setup-node@v2
        with:
          node-version: 14.x

      - name: Install dependencies
        run: npm install

      - name: Validate all commits from PR
        run: npx commitlint --from $ github.event.pull_request.base.sha  --to $ github.event.pull_request.head.sha  --verbose

【讨论】：

在没有拉取请求的情况下直接推送到 master 的提交怎么样？

这实际上是我的可怜，因为推送到 master 的提交实际上不应该被覆盖。抱歉问了。

@KutsanKaplan 你的问题有道理。您需要在on: 部分中指定分支。看看official documentation。

【参考方案2】：

git rev-list 被认为是因为拉取请求 (PR) 的提交似乎无效。不需要循环。

issue 提示检查 PR 分支，这似乎比获取 PR 提交更简单。从问题来看，似乎不需要对默认分支进行测试。

- uses: actions/checkout@v2
        with:
          fetch-depth: 0
          ref: $ github.event.pull_request.base.sha 

lint 指令是：

npx commitlint --from $ github.event.pull_request.base.sha  --verbose

pull-request payload 的文档 不会立即提供提交列表。

【讨论】：

嘿，谢谢你的帮助！ :) 我很快就会用这个工作流程pastebin.com/zT8X8wLw 试试你的建议

所以我试了一下，但不幸的是 lint 指令不起作用。我在imgur imgur.com/a/XFvYnK5上传了完整的日志，简短的错误信息是：[input] is required: supply via stdin, or --env or --edit or --from and --to

确实，不提供参数时使用stdin。建议的命令用 --from 标志补充。

不幸的是，这没有帮助。尽管我创建了一个有效的提交消息，一个无效的提交消息，然后我创建了一个有效的最后一个，但工作流通过了。我希望工作流程失败，因为第二个无效。但工作流程通过了。

您似乎暗示只测试相关的提交。 linting 规则不是问题。预期的差异是多少？