MEP19：持续集成#

状态#

完全的

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

测试

matplotlib 目前使用 Travis-CI 进行自动化测试。虽然 Travis-CI 作为一项免费服务应该受到称赞，但它有许多缺点：

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

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

构建

matplotlib 的自动二进制构建没有集中的工作。但是，正在做以下不同的事情[如果这里提到的作者可以详细填写，那就太好了！]：

文档

main 的文档现在由 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 上启用测试产品的 Amazon S3 上传。这将有助于对故障进行事后分析（@mdboom 正在调查此问题）。
我们想要 Mac 覆盖率。最好的选择可能是推动 Travis 为我们的项目启用它，方法是向他们支付 Pro 帐户的费用（因为他们不允许在 Linux 和 Mac 上进行测试）。
我们想要 Windows 覆盖。在那里，Shining Panda 是一个选择。
调查发现或构建一个工具，该工具将从多个来源收集和综合测试结果，并使用 GitHub API 将其发布到 GitHub。这可能对 Scipy 社区很有用。
对于 Windows 和 Mac，我们应该记录（或者更好的是，编写脚本）设置机器以进行构建的过程，以及如何构建二进制文件和安装程序。这可能需要从 Russel Owen 和 Christoph Gohlke 获取信息。这是进行自动化构建的必要步骤，但由于许多其他原因也很有价值。