我正在考虑让中央存储库（Mercurial）运行一个预提交钩子来验证已经进入的代码，如果它导致构建或单元测试失败，则禁止推送。
一个明显的缺点是构建需要几分钟，并且会让开发人员一直挂起直到完成。
有没有人做过类似的事情或有任何意见？
答案 0 :(得分：10)
对我而言，这是一种反模式。 Mercurial是一个VERSION CONTROL SYSTEM，用于对您的资源进行版本控制。它不是构建系统，持续集成系统，单元测试套件或类似的东西。您应该将这样的事情委托给适当的工具，而不是预先提交类型的钩子。我将使用名为Jenkins的开源持续集成套件（http://jenkins-ci.org/）并在commit / push上执行build / test / etc。您可以根据构建结果将Jenkins配置为执行大量操作。
答案 1 :(得分：3)
它被称为门控签入或预先测试提交。一些CI系统允许它，有些则不允许。
这是一篇关于TFS做这样事情的博客文章： http://spandothers.wordpress.com/2010/06/08/tfs-2010-gated-check-ins/
恕我直言，这是一个很棒的功能。签入，打破构建，修复它，然后继续。打破构建不应该是一件大事。答案 2 :(得分：3)
Mercurial书涵盖了这个案例http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html。但这里有几点说明：
pretxnchangegroup钩子而不是precommit钩子，因为用户没有进入中央仓库，他们只是推动它。最好让持续集成系统观察中央仓库，在有新的变更集时运行构建，并在测试失败时发出警报。在警报响起之前撤离的人将能够轻松地从打破构建的尴尬编码器中删除修复程序。 http://www.youbrokethebuild.com/
答案 3 :(得分：0)
我通过“门禁登记”或“分阶段登记”的名称知道。
像微软这样的大公司（我曾经工作过的地方）和Sun（无法找到链接）都倾向于增加测试系统的保证和生产力（“构建不会因设计而破坏”）而不是开发人员的生产力（“办理登机手续需要1-2小时”）。只在小公司或小型项目上工作的人通常会被这个想法吓到，但你应该做自己的数学运算。我已经看到了两种方法来实现它（并且我不知道有任何产品可以这样做）：
*客户端：用您自己的常用签入工具（CL，GUI）替换，将更改提交到临时分支（或者只是将diff文件放在某个临时位置），然后触发某些远程执行构建代理，它将进行更改并执行快速构建和基本测试（也称为smote测试）。一切顺利的时候，这些变化都是真正的办理登机手续
*服务器端：设置版本控制，以便人们从“稳定”位置获取代码，但将更改推送到“工作”位置（每个开发人员，团队，无论如何）。然后通过签入到工作位置触发CI服务器，并在成功时自动将它们推入“稳定分支”，或者在失败时将其恢复。
我不提倡这种方法，只要看看哪种方式符合您的需求。