MEP19:持续集成#

状态#

已完成

分支和 Pull requests#

摘要#

matplotlib 可以从更好,更可靠的持续集成中受益,无论是用于测试还是构建安装程序和文档.

详细描述#

当前最新技术#

测试

matplotlib 目前使用 Travis-CI 进行自动化测试. 虽然 Travis-CI 因其作为一项免费服务所做的大量工作而应该受到赞扬,但它存在许多缺点:

  • 在安装依赖项时,它经常因网络超时而失败.

  • 它经常因莫名其妙的原因而失败.

  • 构建或测试产品只能从主存储库分支上的构建中保存,而不能从拉取请求中保存,因此通常很难"事后"分析出错的原因. 当无法随后在本地重现失败时,这尤其令人沮丧.

  • 它不是非常快. matplotlib 的 CPU 和内存测试要求远高于一般的 Python 项目.

  • 它只在 Ubuntu Linux 上进行测试,并且我们对平台的具体细节只有最少的控制. 它可以随时在我们无法控制的情况下进行升级,从而在我们的发布计划中可能不方便的时候造成意外的延迟.

从好的方面来说,Travis-CI 与 github 的集成--自动测试所有待处理的拉取请求--非常出色.

构建

matplotlib 目前没有用于自动二进制构建的集中式工作. 但是,正在完成以下不同的事情 [如果此处提到的作者可以填写详细信息,那就太好了!]:

  • @sandrotosi:构建 Debian 软件包

  • @takluyver:在 Launchpad 上进行了自动 Ubuntu 构建

  • @cgohlke:制作 Windows 构建(不知道自动化程度如何)

  • @r-owen:制作 OS-X 构建(不知道自动化程度如何)

文档

main 的文档现在由 travis 构建并上传到 https://matplotlib.org/devdocs/index.html

@NelleV,我相信,会自动生成文档并将其发布到网上以绘制 MEP10 的进度.

matplotlib 的特性#

matplotlib 的复杂需求使得测试和构建比许多其他 Python 项目更繁重.

  • 运行测试所需的 CPU 时间非常长.这使得我们无法使用许多 CI 服务的免费帐户(例如 ShiningPanda).

  • 它有大量的依赖项,测试所有组合的完整矩阵是不切实际的.我们需要巧妙地决定测试哪些方面并保证支持.

需求#

本节概述了我们希望拥有的需求.

  1. 通过连接到 GitHub API 来测试所有 pull request,就像 Travis-CI 所做的那样

  2. 在所有主要平台上进行测试:Linux,Mac OS-X,MS Windows(按用户调查的优先级顺序排列)

  3. 保留最近 n 天的构建和测试产品,以帮助进行事后调试.

  4. 自动化的每晚二进制构建,以便用户可以在不安装完整编译环境的情况下测试最新版本.

  5. 自动化的基准测试.如果有一个标准基准测试套件(与测试分开),其性能可以随着时间的推移在不同的后端和平台上进行跟踪,那就太好了.虽然这与构建和测试分开,但理想情况下,它应该在相同的基础设施上运行.

  6. 自动化的每晚构建和发布文档(或作为测试的一部分,以确保 PR 不会引入文档错误).(这不会取代稳定版本的静态文档作为默认设置).

  7. 测试系统应该可以由多个开发人员管理,这样就不会有任何一个人成为瓶颈.(Travis-CI 的设计在这方面做得很好 -- 将构建配置存储在 git 存储库中,而不是其他地方,这是一个非常好的设计.)

  8. 使其易于测试 matplotlib 依赖项的不同版本的大而稀疏的矩阵.matplotlib 用户调查提供了一些很好的数据,可以帮助我们确定工作的重点:https://docs.google.com/spreadsheets/d/1jbK0J4cIkyBNncnS-gP7pINSliNy9lI-N4JHwxlNSXE/edit

  9. 最好有:一种去中心化的设计,以便那些拥有更晦涩平台的开发人员可以将构建结果发布到中央仪表板.

实施#

这部分尚未编写.

但是,理想情况下,该实现将是第三方服务,以避免将系统管理添加到我们已经捉襟见肘的时间中.由于我们有一些捐赠资金,如果此服务与免费产品相比提供了显着的时间节省优势,那么它可能是有偿服务.

向后兼容性#

向后兼容性不是此 MEP 的主要关注点.我们将用更好的东西替换当前的工具和程序,并抛弃旧的.

替代方案#

Hangout 笔记#

CI 基础设施#

  • 我们喜欢 Travis,并且无论如何它可能仍然是我们武器库的一部分.可靠性问题正在调查中.

  • 在 Travis 上启用 Amazon S3 上传测试产品.这将有助于对失败进行事后分析(@mdboom 正在调查此事).

  • 我们想要 Mac 覆盖.最好的办法可能是通过为我们的项目付费购买 Pro 帐户来推动 Travis 为我们启用它(因为他们不允许在 Linux 和 Mac 上同时进行测试).

  • 我们想要 Windows 覆盖.Shining Panda 是一个选择.

  • 调查寻找或构建一种工具,该工具可以从多个来源收集和综合测试结果,并使用 GitHub API 将其发布到 GitHub.这可能对 Scipy 社区具有普遍用途.

  • 对于 Windows 和 Mac,我们应该记录(或者更好的是,编写脚本)设置机器以进行构建的过程,以及如何构建二进制文件和安装程序.这可能需要从 Russel Owen 和 Christoph Gohlke 处获取信息.这是进行自动构建的必要步骤,但对于许多其他原因也很有价值.

测试框架本身#

  • 我们应该调查使它花费更少时间的方法

    • 如果可能,消除冗余测试

    • matplotlib 的总体性能改进将有所帮助

  • 我们应该涵盖更多内容,尤其是更多后端

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