Continuous Integration System for a Python Codebase我开始使用Python代码库从事一个业余项目，并且我想建立某种形式的持续集成(即，每次签入时都要运行一堆测试用例，并向负责人发送垃圾邮件) 测试失败的人员)类似于CruiseControl或TeamCity。 我意识到我可以在大多数VCS中使用钩子来做到这一点，但是这要求测试必须与版本控制服务器在同一台计算机上运行，这并不像我所希望的那样优雅。 对于适合于Python代码库的小型，用户友好型，开源持续集成系统，是否有人有任何建议？ 我们在工作中运行Buildbot-Trac。因为我的代码库还不是发布周期的一部分，所以我没有使用太多。但是我们在不同的环境(OSX / Linux / Win)上运行测试，并且它发送电子邮件-它是用Python编写的。 哈德森就是一种可能性。它是用Java编写的，但是与Python项目集成在一起：
但是，我从来没有尝试过。 (2011年9月更新：在商标争议之后，Hudson已重命名为Jenkins。)
其次是Buildbot-Trac集成。您可以在Buildbot网站上找到有关集成的更多信息。在上一份工作中，我们编写并使用了他们提到的插件(tracbb)。 Buildbot的真正好处是配置是用Python编写的。您可以将自己的Python代码直接集成到配置中。编写自己的BuildSteps以执行特定任务也非常容易。 我们使用BuildSteps从SVN获取源代码，提取依赖项，将测试结果发布到WebDAV等。 我写了一个X10接口，以便我们发送带有构建结果的信号。当构建失败时，我们打开了红色熔岩灯。构建成功后，绿色熔岩灯会亮起。美好时光 ：-) 我们将Buildbot和Hudson都用于Jython开发。两者都是有用的，但是有不同的优点和缺点。 Buildbot的配置是纯Python的，一旦掌握了它，它就非常简单(有关最新信息，请参阅epydoc生成的API文档)。 Buildbot使定义非测试任务和分发测试人员变得更加容易。但是，它实际上没有单个测试的概念，仅包含文本，HTML和摘要输出，因此，如果要具有多级可浏览的测试输出等，则必须自己构建或使用Hudson。 Hudson为从整体结果深入到测试套件和单个测试提供了出色的支持。这对于比较内部版本之间的测试输出也非常有用，但是分布式(主/从)内容相对较为复杂，因为在从属服务器上也需要Java环境。而且，哈德森对主机和从机之间不稳定的网络链接的容忍度也较低。 因此，为了获得这两种工具的好处，我们运行了一个Hudson实例，该实例捕获了常见的测试失败，然后使用Buildbot进行了多平台回归。 这是我们的实例：
我们正在使用与Trac集成的Bitten wich。它是基于python的。 TeamCity具有一些Python集成。 但是TeamCity是：
对于较小的代码库，我在Travis-CI方面有很好的经验。
一些限制：
|
