MEP19:持续集成

状态

Completed

分支和请求

摘要

Matplotlib可以从更好、更可靠的持续集成中获益,无论是测试、构建安装程序还是文档。

详细描述

最新技术

Testing

Matplotlib目前使用Travis CI进行自动测试。Travis CI作为一种免费服务应该受到表扬,但它有许多缺点:

  • 在安装依赖项时,它通常会由于网络超时而失败。
  • 它经常因为莫名其妙的原因而失败。
  • 构建或测试产品只能从主回购分支的构建中保存,而不能提取请求,因此通常很难“事后”分析出哪里出错。当故障随后无法在本地再现时,这尤其令人沮丧。
  • 它不是非常快。Matplotlib对测试的CPU和内存需求远远高于平均的Python项目。
  • 它只在UbuntuLinux上进行测试,我们对平台的细节控制很少。它可以在我们无法控制的任何时候升级,在我们的发布计划中可能不方便的时候造成意外的延迟。

另一方面,TravisCI与Github的集成——自动测试所有挂起的拉请求——是非常出色的。

Builds

对于Matplotlib的自动化二进制构建没有集中的工作。但是,正在做以下不同的事情 [如果这里提到的作者能详细填写,那就太好了!] :

  • @Sandrotosi:构建Debian包
  • @Takluyver:在LaunchPad上有自动的Ubuntu构建
  • @cgohlke:使Windows生成(不知道这是如何自动化的)
  • @R-欧文:做OS-X构建(不知道这有多自动化)

Documentation

主文件现在由Travis建立并上传到http://matplotlib.org/devdocs/index.html。

@我相信,Nellev会自动生成文档,并将它们发布到Web上,以记录MEP10的进度。

Matplotlib的特点

Matplotlib有复杂的需求,这使得测试和构建比许多其他Python项目更为繁重。

  • 运行测试的CPU时间相当长。它使我们超越了许多CI服务的免费帐户(如ShiningPanda)
  • 它有大量的依赖关系,并且测试所有组合的完整矩阵是不切实际的。我们需要对我们测试和保证支持的空间保持聪明。

要求

本节概述了我们想要的要求。

  1. 通过挂接到GitHub API来测试所有请求,如Travis CI所做的那样
  2. 在所有主要平台上进行测试:Linux、Mac OS-X、MS Windows(根据用户调查,按优先级排列)
  3. 保留过去n天的构建和测试产品,以帮助后期调试。
  4. 每晚自动生成二进制文件,这样用户就可以在不安装完整编译环境的情况下测试出血边缘。
  5. 自动化基准测试。最好有一个标准的基准套件(与测试分开),它的性能可以随着时间的推移在不同的后端和平台上进行跟踪。虽然这与构建和测试是分开的,但理想情况下它将在同一基础设施上运行。
  6. 每晚自动构建和发布文档(或作为测试的一部分,以确保PRS不会引入文档错误)。(这不会将稳定版本的静态文档替换为默认版本)。
  7. 测试系统应该由多个开发人员管理,这样就不会有任何一个人成为瓶颈。(TravisCI的设计做得很好——将构建配置存储在Git存储库中,而不是其他地方,是一个非常好的设计。)
  8. 使测试不同版本matplotlib依赖项的大型稀疏矩阵变得容易。matplotlib用户调查提供了一些很好的数据,说明我们的工作重点是什么:https://docs.google.com/spreadsheet/ccc?键=0ajrpjltmtwtdhpqs25pctzirwdqx0pncknsu01smhc
  9. 很好拥有:一个去中心化的设计,这样那些拥有更模糊平台的人可以将构建结果发布到一个中央仪表盘。

实施

这部分还没有写完。

然而,理想情况下,实现将是第三方服务,以避免在我们已经延长的时间内添加系统管理。由于我们有一些捐赠的资金,如果这项服务比免费服务具有显著的节省时间的优势,那么它可能是付费服务。

向后兼容性

向后兼容性不是此MEP的主要关注点。我们将用更好的东西替换现有的工具和过程,并扔掉旧的。

选择

流浪笔记

CI基础设施

  • 我们喜欢特拉维斯,无论如何它都可能是我们阿森纳的一部分。可靠性问题正在调查中。
  • 在Travis上允许AmazonS3上传测试产品。这将有助于解决故障的事后分析(@mdboom现在正在研究这个问题)。
  • 我们需要MAC覆盖。最好的办法可能是通过向Travis支付一个pro帐户(因为他们不允许在Linux和Mac上进行测试)来推动Travis为我们的项目启用它。
  • 我们需要视窗覆盖。闪亮的 Pandas 是一种选择。
  • 研究如何找到或构建一个工具来收集和合成来自多个源的测试结果,并使用GitHub API将其发布到GitHub。这可能对Scipy社区有普遍的用途。
  • 对于Windows和Mac,我们应该记录(或者更好的是,编写脚本)为构建设置机器的过程,以及如何构建二进制文件和安装程序。这可能需要从Russel Owen和Christoph Gohlke那里获得信息。这是进行自动化构建的必要步骤,但由于许多其他原因,这也是很有价值的。

测试框架本身

  • 我们应该研究如何缩短时间

    • 尽可能消除冗余测试
    • Matplotlib的一般性能改进将有助于
  • 我们应该覆盖更多的东西,特别是更多的后端

  • 如果可能的话,我们应该有更多的单元测试,更少的集成测试