Skip to content

持续集成

Polars 使用 GitHub Actions 作为其持续集成（CI）工具。就 CI 设置而言，该设置相当复杂。本页解释了一些设计选择。

目标

总体而言，CI套件旨在实现以下目标：

  • 通过运行自动化测试来确保代码的正确性。
  • 通过运行自动化的代码质量检查来强制执行代码质量。
  • 通过运行基准测试来强制执行代码性能。
  • 确保代码有适当的文档记录。
  • 允许维护者轻松发布新版本。

我们依赖多种工具来实现这一点，无论是Rust还是Python代码库，因此每次拉取请求都会触发大量检查。

完全有可能你提交了一个相对较小的修复，但随后却未能通过一系列检查。不要灰心——检查日志以查看出了什么问题，并尝试修复它。你可以在本地运行失败的命令，以验证一切是否正常。如果你无法弄清楚，可以向维护者寻求帮助！

设计

CI 设置的设计考虑了以下要求：

  • 分别获取每个步骤的反馈。我们希望避免因为一个代码检查失败而导致我们的测试任务被取消，结果后来发现我们还有一个失败的测试。
  • 尽快获取每次检查的反馈。我们希望如果发现我们的代码未能通过某些检查，能够快速进行迭代。
  • 仅在需要时运行检查。例如，对Rust代码的更改并不需要对Python代码进行linting检查。

这导致了一个模块化的设置，其中包含许多独立的工作流和作业，这些工作流和作业严重依赖缓存。

模块化设置

该仓库由两个主要部分组成：Rust代码库和Python代码库。这两个代码库相互依赖：Rust代码通过Python测试进行测试，而Python代码则依赖于Rust实现来完成大部分功能。

为了确保CI作业仅在需要时运行，每个工作流仅在相关文件被修改时触发。

缓存

主要挑战在于Polars的Rust代码库相当庞大，因此从头编译项目速度较慢。这个问题通过缓存Rust构建产物来解决。

然而，由于 GitHub Actions 不允许在功能分支之间共享缓存，我们还需要在主分支上运行工作流——至少是构建 Rust 缓存的部分。这导致许多工作流在拉取请求和推送到主分支时都会触发，并且根据运行的分支启用或禁用作业的各个步骤。

还必须注意不要超过分配给开源GitHub存储库的最大缓存空间10Gb。因此，我们不在功能分支上进行任何缓存 - 我们始终使用主分支上可用的缓存。这也避免了存储缓存所需的额外时间。

版本发布

Rust 和 Python 的发布工作是手动触发的。有关完整发布流程，请参阅 贡献指南。