如何同步 CI 和我的预提交检查？

Question

我设置了一些预提交钩子，在诗歌管理项目中使用诗人库运行这些钩子，这些钩子运行得很好。

我还开始通过 TravisCI 设置 CI 管道，目前这只是运行我的单元测试。

但是，知道将来这个项目可能会成为协作项目，我想确保我同事的代码仍然经过这些检查，即使由于某种原因他们使用

git commit

选项运行

git push

或

--no-verify

。

想要将预提交挂钩的作业与实际的 CI 管道同步是一个好的实践吗？我开始质疑它，因为我很难找到资源来尝试做到这一点。

如果由于某种原因在 CI 管道中重新应用预提交作业不是一个好的做法，那么当您已经在使用预提交库时，在 CI 管道中运行 linter 的常见方法是什么？

最后，我希望有一种方法来确保我在预提交工作中使用的 linter 版本与 CI 管道中使用的版本相同（并且易于维护，这意味着如果我决定更新Ruff 钩子，我想确保 CI 管道中使用的 Ruff 版本也已更新）。

谢谢您的帮助

Answer 1

您认为应该在 CI 中运行钩子并将其作为预提交钩子的怀疑是有根据的。预提交挂钩无法运行的原因有很多：

• 正如您提到的，有人使用

  --no-verify

  （注意：这可能并不总是恶意的。它当然有可能处于损坏状态，但仍然想推送到远程分支以进行备份）。
• 根据您的预提交框架，可能会忘记设置/安装挂钩
• 可能更多

那么，假设您打算在 CI 中运行这些钩子并将其作为预提交钩子，那么减少代码重复的最佳方法是什么？

这可能在很大程度上取决于您首选的钩子框架，但我通常的策略是使每个钩子成为一个独立的脚本。可以随时按需运行的东西。这使得运行变得非常容易：

• 作为预提交挂钩：实际挂钩仅调用 lint 脚本
• 在 CI 中：CI 作业步骤调用 lint 脚本
• 调试时按需：执行脚本

总的来说，我发现这使得重用这种类型的预签入（或至少预合并）变得非常方便，并且代码重复最少。

预期的问题

为什么要费心使用 CI 和预提交挂钩？只用一个岂不是更少重复？

在 CI 和预提交挂钩中运行验证有好处：

CI 中的验证：这是您可以“保证”的唯一验证（假设对远程存储库、受保护分支等具有正确的访问权限）如上所述，有一些方法可以避免预提交挂钩。因此，在 CI 中运行验证是维护项目的唯一可靠方法。
预提交钩子中的验证：这将帮助您在问题到达 CI 之前捕获问题，从而在开发时为您提供更快的反馈，并避免在运行器上消耗 CI 分钟/消耗云资源。