Python 代码库的持续集成系统
我开始使用 Python 代码库开展一个业余爱好项目，我想设置某种形式的持续集成（即每次签入时运行一组测试用例，并且测试失败时向负责人发送提醒电子邮件）类似于 CruiseControl 或 TeamCity。
我意识到我可以在大多数VCS中使用钩子来做到这一点，但这需要测试在与版本控制服务器相同的机器上运行，这并不像我想要的那么优雅。 有人对适合 Python 代码库的小型、用户友好、开源持续集成系统有什么建议吗？
I am starting to work on a hobby project with a Python codebase and I would like to set up some form of continuous integration (i.e. running a battery of test-cases each time a check-in is made and sending nag e-mails to responsible persons when the tests fail) similar to CruiseControl or TeamCity.
I realize I could do this with hooks in most VCSes, but that requires that the tests run on the same machine as the version control server, which isn't as elegant as I would like. Does anyone have any suggestions for a small, user-friendly, open-source continuous integration system suitable for a Python codebase?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我们在工作中运行 Buildbot - Trac。 我没有太多地使用它，因为我的代码库还不是发布周期的一部分。 但我们在不同的环境（OSX/Linux/Win）上运行测试，它会发送电子邮件——而且是用 Python 编写的。
We run Buildbot - Trac at work. I haven't used it too much since my codebase isn't part of the release cycle yet. But we run the tests on different environments (OSX/Linux/Win) and it sends emails — and it's written in Python.
对于较小的代码库，我在 Travis-CI 方面拥有非常好的经验。
主要优点是：
一些限制：
Python 不被支持作为第一类语言（截至撰写本文时；但您可以使用 pip 和 apt-get 安装 python 依赖项；请参阅 本教程)
代码必须托管在github上（至少在使用官方版本时）
I have very good experiences with Travis-CI for smaller code bases.
The main advantages are:
Some limitations:
Python is not supported as a first class language (as of time of writing; but you can use pip and apt-get to install python dependencies; see this tutorial)
code has to be hosted on github (at least when using the official version)
一种可能性是哈德森。 它是用 Java 编写的，但与 Python 项目集成：
不过，我自己从未尝试过。
（更新，2011 年 9 月：商标纠纷后，Hudson 更名为 Jenkins .)
One possibility is Hudson. It's written in Java, but there's integration with Python projects:
I've never tried it myself, however.
(Update, Sept. 2011: After a trademark dispute Hudson has been renamed to Jenkins.)
其次是 Buildbot - Trac 集成。 您可以在 Buildbot 网站 上找到有关集成的更多信息。 在我之前的工作中，我们编写并使用了他们提到的插件（tracbb）。
该插件的作用是重写所有 Buildbot url，以便您可以在 Trac 中使用 Buildbot。 （http://example.com/tracbb）。
Buildbot 真正好的一点是配置是用 Python 编写的。 您可以将自己的 Python 代码直接集成到配置中。 编写自己的 BuildSteps 来执行特定任务也很容易。
我们使用 BuildSteps 从 SVN 获取源代码、提取依赖项、将测试结果发布到 WebDAV 等。
我编写了一个 X10 接口，以便我们可以发送带有构建结果的信号。 当构建失败时，我们打开了一盏红色熔岩灯。 构建成功后，绿色熔岩灯亮起。 美好时光 ：-）
Second the Buildbot - Trac integration. You can find more information about the integration on the Buildbot website. At my previous job, we wrote and used the plugin they mention (tracbb).
What the plugin does is rewriting all of the Buildbot urls so you can use Buildbot from within Trac. (http://example.com/tracbb).
The really nice thing about Buildbot is that the configuration is written in Python. You can integrate your own Python code directly to the configuration. It's also very easy to write your own BuildSteps to execute specific tasks.
We used BuildSteps to get the source from SVN, pull the dependencies, publish test results to WebDAV, etcetera.
I wrote an X10 interface so we could send signals with build results. When the build failed, we switched on a red lava lamp. When the build succeeded, a green lava lamp switched on. Good times :-)
我们使用 Buildbot 和 Hudson 进行 Jython 开发。 两者都很有用，但有不同的优点和缺点。
Buildbot 的配置是纯 Python 的，一旦掌握了它的窍门就非常简单（请查看 epydoc 生成的 API 文档以获取最新信息）。 Buildbot 使定义非测试任务和分配测试人员变得更加容易。 然而，它实际上没有单独测试的概念，只有文本、HTML 和摘要输出，因此如果您想要多级可浏览的测试输出等，您必须自己构建它，或者只使用 Hudson。
Hudson 对从总体结果深入到测试套件和单独测试提供了极好的支持； 它也非常适合比较构建之间的测试输出，但分布式（主/从）的东西相对更复杂，因为您也需要在从属上有一个 Java 环境； 此外，Hudson 对主从之间不稳定的网络链接的容忍度较低。
因此，为了获得这两种工具的优势，我们运行 Hudson 的单个实例，它捕获常见的测试失败，然后我们使用 Buildbot 进行多平台回归。
以下是我们的实例：
We use both Buildbot and Hudson for Jython development. Both are useful, but have different strengths and weaknesses.
Buildbot's configuration is pure Python and quite simple once you get the hang of it (look at the epydoc-generated API docs for the most current info). Buildbot makes it easier to define non-testing tasks and distribute the testers. However, it really has no concept of individual tests, just textual, HTML, and summary output, so if you want to have multi-level browsable test output and so forth you'll have to build it yourself, or just use Hudson.
Hudson has terrific support for drilling down from overall results into test suites and individual tests; it also is great for comparing test output between builds, but the distributed (master/slave) stuff is comparatively more complicated because you need a Java environment on the slaves too; also, Hudson is less tolerant of flaky network links between the master and slaves.
So, to get the benefits of both tools, we run a single instance of Hudson, which catches the common test failures, then we do multi-platform regression with Buildbot.
Here are our instances:
TeamCity 有一些 Python 集成。
但TeamCity的特点是：
TeamCity has some Python integration.
But TeamCity is:
我们正在使用与 trac 集成的 Bitten。 它是基于Python的。
We are using Bitten wich is integrated with trac. And it's python based.