跳到内容

持续集成

Polars 使用 GitHub Actions 作为其持续集成 (CI) 工具。就 CI 设置而言，其配置相当复杂。本页面解释了部分设计选择。

目标

总的来说，CI 套件旨在实现以下目标

  • 通过运行自动化测试来确保代码的正确性。
  • 通过运行自动化 Linting 检查来确保代码质量。
  • 通过运行基准测试来确保代码性能。
  • 确保代码得到妥善文档化。
  • 允许维护者轻松发布新版本。

为此，我们为 Rust 和 Python 代码库使用了各种工具，因此每次拉取请求都会触发大量检查。

你提交的修复可能相对简单，但随后却未能通过大量检查，这种情况完全可能发生。不要气馁——检查日志以查看出了什么问题并尝试修复它。你可以在本地运行失败的命令，以验证一切是否正常工作。如果你无法解决，请向维护者寻求帮助！

设计

CI 设置在设计时考虑了以下要求

  • 针对每个步骤单独获取反馈。我们希望避免测试任务因 Linting 检查失败而被取消，却在之后才发现我们也有失败的测试。
  • 尽快获取每次检查的反馈。如果发现代码未能通过某些检查，我们希望能够快速迭代。
  • 只在需要时运行检查。例如，对 Rust 代码的更改不需要对 Python 代码进行 Linting 检查。

这使得我们能构建一个模块化设置，其中包含许多独立的工作流和任务，它们都严重依赖缓存。

模块化设置

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

为确保 CI 任务只在需要时运行，每个工作流只在相关文件被修改时才会被触发。

缓存

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

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

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

发布

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