推送时构建和单元测试？
我正在考虑让中央存储库（Mercurial）运行一个预提交挂钩来验证已进入的代码，如果它导致构建或单元测试失败，则不允许推送。
这样做的一个明显的缺点是构建需要几分钟，并且会让开发人员等待直到完成。
有没有人做过类似的事情，或者有什么意见？
I'm considering having the central repository (Mercurial) run a pre-commit hook that validates the code that has come in, and if it results in a failed build or unit test, disallows the push.
One obvious downside for this is that the build takes a couple of minutes, and would leave the developer hanging until it was complete.
Has anyone done anything similar, or have any comments?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对我来说，这是一种反模式。 Mercurial 是一个版本控制系统，用于对源代码进行版本控制。它不是构建系统、持续集成系统、单元测试套件或类似的东西。您应该将此类事情委托给适当的工具，而预提交类型挂钩不适合。我将使用名为 Jenkins (http://jenkins-ci.org/) 的开源持续集成套件，并在提交/推送时执行构建/测试/等操作。您可以配置 Jenkins 根据构建结果执行大量操作。
To me, this is an anti-pattern. Mercurial, a VERSION CONTROL SYSTEM, is to version your sources. It is not a build system, continuous integration system, unit testing suite or anything like that. You should delegate things like this to the appropriate tool and a pre-commit type hook is not the place. I would use the open source continuous integration suite called Jenkins (http://jenkins-ci.org/) and do the build/test/etc upon commit/push. You can configure Jenkins to do a plethora of things based on the build results.
它称为门控签入或预测试提交。有些 CI 系统允许，有些则不允许。
这是一篇关于 TFS 执行此类操作的博客文章：
http://spandothers.wordpress.com/2010/ 06/08/tfs-2010-gate-check-ins/
恕我直言，这是一个无聊的功能。签入、中断构建、修复它，然后继续。破坏构建应该没什么大不了的。
Its called a gated check-in, or pretested-commit. Some CI systems allow it, some don't.
Here's a blog article about TFS doing such a thing:
http://spandothers.wordpress.com/2010/06/08/tfs-2010-gated-check-ins/
IMHO, its a meh feature. Check-in, break the build, fix-it, and move-on. Breaking the build should not be that big of a deal.
Mercurial 书介绍了这种情况 http://hgbook.red -bean.com/read/handling-repository-events-with-hooks.html 。但这里有一些注意事项：
pretxnchangegroup挂钩，而不是precommit挂钩，因为用户没有提交到中央存储库，他们只是推送到它。意义最好让您的持续集成系统监视中央存储库，在出现新变更集时运行构建，并在测试失败时发出警报。在警报响起之前拉出的人将能够轻松地从破坏构建的尴尬编码员那里拉出修复程序。 http://www.youbrokethebuild.com/
The Mercurial book covers this case http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html . but here are a few notes:
pretxnchangegrouphook not aprecommithook since the users aren't committing to the central repo, they're just pushing to it.You're better off just having your continuous integration system watch the central repo, run a build whenever there are new changesets and sound the alarm when tests fail. People who pulled before the alarm sounded will be easily able to pull down the fixes from the embarassed coder who broke the build. http://www.youbrokethebuild.com/
我通过“门禁办理登机”或“分阶段办理登机”的名称来了解它。
像 Microsoft（我曾经工作过的地方）和 Sun（找不到链接）这样的大公司更喜欢测试系统的额外保证和生产力（“构建不会破坏，设计”）而不是开发人员的生产力（“检查-需要 1-2 小时”）。只在小公司或小项目工作的人通常会被这个想法吓坏，但你应该自己算算。
我已经看到了两种自己实现它的方法（并且不知道有任何产品可以这样做）：
* 客户端：用您自己的工具替换常见的签入工具（CL、GUI），该工具会将更改提交到临时分支（或者只是将 diff 文件放在某个临时位置），然后触发某些远程命令的执行构建代理将接受更改并执行快速构建和基本测试（也称为 smote 测试）。当一切顺利时，更改才真正被签入。
* 服务器端：设置版本控制，使人们从“稳定”位置获取代码，但将更改推送到“工作”位置（每个开发人员、团队或其他位置一个）。然后，通过签入工作位置来触发 CI 服务器，并在成功时自动将它们推送到“稳定分支”，或在失败时将它们恢复。
我不提倡这种方法，看看什么适合你的需求。
I know it by the names of "gated check-in" or "staged check-in".
Big companies like Microsoft (where I used to work) and Sun (could not find the link) favor the added assurance and productivity of the testing systems ("build can't break, by design") over the productivity of developers ("check-in takes 1-2 hours"). People which worked only on small companies or small projects usually freak out by the idea, but you should do your own math.
I've seen two ways to implement it yourself (and am not aware of any product which do so):
* Client-side: replace the common check-in tool (CL, GUI) with your own which will commit the changes into a temporary branch (or will just put the diff file in some temporary location), then trigger the execution of some remote build agent which will take the changes and perform a fast build and basic testing (aka smote tests). When all is well, the changes are really checked-in.
* Server-side: set up your version control in such a way that people get code from a "stable" location but push changes into "work" location (one per developer, team, whatever). Then have a CI server triggered by check-ins into the work location and automatically push them into the "stable branch" upon success or revert them upon failure.
I don't advocate this approach, just see what fits your needs.