MEP19: 持续集成#

状态#

已完成

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

测试

matplotlib 目前使用 Travis-CI 进行自动化测试。虽然 Travis-CI 作为一个免费服务应该因其所做的大量工作而受到赞扬，但它也有一些缺点：

在安装依赖项时，由于网络超时，它经常失败。
它经常因为无法解释的原因而失败。
构建或测试产品只能从主仓库的分支构建中保存，而不是从拉取请求中保存，因此通常很难进行“事后”分析出了什么问题。当失败无法在本地随后重现时，这尤其令人沮丧。
它不是非常快。matplotlib 的 CPU 和内存测试要求远高于一般的 Python 项目。
它仅在 Ubuntu Linux 上进行测试，并且我们对该平台的具体细节控制有限。它可以在我们无法控制的情况下随时升级，有时可能会导致在我们的发布计划中不方便的时候出现意外延迟。

另一方面，Travis-CI 与 github 的集成——自动测试所有待处理的拉取请求——非常出色。

构建

目前没有针对matplotlib的自动化二进制构建的集中化努力。然而，以下是一些正在进行的分散工作 [如果这里提到的作者能够补充细节，那就太好了！]：

文档

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

@NelleV 我相信，会自动生成文档并将它们发布到网上，以记录 MEP10 的进展。

matplotlib 有复杂的要求，这使得测试和构建比许多其他 Python 项目更加繁重。

本节概述了我们希望满足的要求。

通过钩入GitHub API来测试所有拉取请求，就像Travis-CI所做的那样
在所有主要平台上进行测试：Linux、Mac OS-X、MS Windows（按用户调查的优先顺序排列）
保留最近 n 天的构建和测试产品，以协助事后调试。
自动化的夜间二进制构建，以便用户可以在不安装完整编译环境的情况下测试前沿版本。
自动化基准测试。拥有一个标准的基准测试套件（与测试分开）会很好，其性能可以在不同后端和平台上随时间跟踪。虽然这与构建和测试分开，但理想情况下它会在相同的基础设施上运行。
自动化的夜间文档构建和发布（或作为测试的一部分，以确保PR不会引入文档错误）。（这不会替代稳定版本的静态文档作为默认设置）。
测试系统应由多个开发者管理，以避免任何单一人员成为瓶颈。（Travis-CI 的设计做得很好——将构建配置存储在 git 仓库中，而不是其他地方，是一个非常好的设计。）
使测试大量但稀疏的不同版本的 matplotlib 依赖矩阵变得容易。matplotlib 用户调查提供了一些很好的数据，告诉我们应该在哪里集中我们的努力：https://docs.google.com/spreadsheets/d/1jbK0J4cIkyBNncnS-gP7pINSliNy9lI-N4JHwxlNSXE/edit
值得拥有：一个去中心化的设计，以便那些使用较为小众平台的人可以将构建结果发布到一个中央仪表板。

这部分尚未撰写。

然而，理想情况下，实现应该是一个第三方服务，以避免在我们的时间已经很紧张的情况下增加系统管理。由于我们有一些捐赠资金，如果这项服务提供的节省时间优势明显超过免费服务，那么它可能是一项付费服务。

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

我们喜欢 Travis，它很可能会继续成为我们工具库的一部分。可靠性问题正在被调查中。
在 Travis 上启用 Amazon S3 上传测试产品。这将有助于失败后的分析（@mdboom 正在研究这个问题）。
我们希望覆盖Mac系统。最好的办法可能是通过购买Pro账户来推动Travis为我们的项目启用Mac支持（因为他们通常不允许在Linux和Mac上同时进行测试）。
我们希望覆盖Windows。Shining Panda 是一个选项。
调查寻找或构建一个工具，该工具能够从多个来源收集和综合测试结果，并使用GitHub API将其发布到GitHub。这可能对Scipy社区普遍有用。
对于Windows和Mac，我们应该记录（或更好的是，编写脚本）设置机器以进行构建的过程，以及如何构建二进制文件和安装程序。这可能需要从Russel Owen和Christoph Gohlke获取信息。这是进行自动化构建的必要步骤，但出于其他多种原因，这也是有价值的。