持续集成#

持续集成 (CI) 是我们开发流程的一部分，它确保贡献到 SciPy 的每一块代码或文档都能正常工作，并且没有不可预见的影响。

注意

在提交或更新您的 PR 之前，请确保您已在本地测试过您的更改。请参阅 提交 PR 之前的清单 和 在本地运行 SciPy 测试。

工作流程#

我们运行了超过 20 种不同的工作流程，使用不同版本的依赖项、不同架构等。为了确保项目的持续状态，PR 必须通过所有这些检查才能被合并。

除了单元测试之外，还会检查文档和文档字符串中的示例。这些是常见的失败工作流程，因为 Sphinx 和 doctests 具有非常严格的规则。这些方面非常重要，因为文档和示例是面向用户的元素。确保这些元素能够正确呈现。

日志可能很长，但您总是能找到构建/测试失败的原因。只需点击 Details 即可访问日志。

以下是所有正在使用的工作流程列表。它们按 CI 资源提供商分组。

GitHub Actions#

  • Lint: PEP8 和代码风格

  • Windows Tests: 为 Windows 运行测试套件

  • Linux Tests: 为 Linux 运行测试套件

  • macOS Tests: 为 macOS (x86_64) 运行测试套件

  • Wheels builder: 为 SciPy 发布版以及 *夜间* 构建构建轮子。

  • Check the rendered docs here!: 文档的实时预览

  • prerelease_deps_coverage_64bit_blas: 使用预发布版本的依赖项并检查覆盖率

  • gcc-9: 使用最低支持的 GCC 版本进行构建，安装轮子，然后使用 python -OO 运行测试套件

  • Array API: 测试 Array API 支持

测试套件在 GitHub Actions 和其他平台上运行，涵盖各种测试/环境条件：Python 和 NumPy 版本（最低支持版本到夜间构建）、32 位与 64 位、不同的编译器等等 - 有关详细信息，请参阅 .yml 配置文件。

CircleCI#

  • build_docs: 构建文档

  • build_scipy

  • run_benchmarks: 验证更改如何影响性能

  • refguide_check: 来自示例和基准测试的 doctests

CirrusCI#

  • Tests: 为特定架构（如 musllinux, arm, aarch）运行测试套件

  • Wheels: 构建和上传一些轮子

跳过#

作为一个开源项目，我们有 CI 资源配额。最终，资源是有限的，我们应该谨慎使用它们。这就是为什么我们要求您在推送更改之前在本地验证您的更改。

根据所提出的更改，您可能希望跳过部分检查。维护者将自行决定在集成之前重新运行某些测试。

可以通过在提交消息中添加特殊文本来跳过 CI

  • [skip actions]: 将跳过 GitHub Actions

  • [skip circle]: 将跳过 CircleCI

  • [skip cirrus]: 将跳过 CirrusCI

  • [docs only]: 将跳过 *除了* CircleCI 检查和 linter 的所有其他检查

  • [lint only]: 将跳过 *除了* linter 的所有其他检查

  • [skip ci]: 将跳过 *所有* CI

当然，您可以将这些组合起来跳过多个工作流程。

此跳过信息应放在新行上。在本例中，我们只更新了文档中的一个 .rst 文件，并要求跳过除相关文档检查之外的所有检查（跳过 Cirrus 和 GitHub Actions 的工作流程）

DOC: improve QMCEngine examples.

[docs only]

由于测试持续时间导致的失败#

一些 CI 作业安装了 pytest-fail-slow，并在测试执行时间超过阈值时报告失败。

  • 默认情况下，所有测试都受到 5 秒的限制；即，在“完整”测试作业中使用选项 --fail-slow=5.0。

  • 所有未标记为 slow (@pytest.mark.slow) 的测试都受到 1 秒的限制；即，在“快速”测试作业中使用选项 --fail-slow=1.0。

  • 使用 pytest.mark.fail_slow 装饰器进行例外处理；例如，测试可以标记为 @pytest.mark.fail_slow(10)，无论它是否属于“快速”或“完整”测试套件，都将为其提供十秒的限制。

如果测试在 PR 开发过程中的任何阶段因超过时间限制而失败，请调整测试以确保将来不会失败。即使新的测试没有失败，在 PR 合并之前，也请检查包含“fail slow”名称的工作流程的详细信息。这些包括接近（或已超过）其时间限制的测试列表。由于执行时间存在差异，因此执行时间接近阈值的测试应进行调整，以避免失败，即使它们的执行时间增加 50%；典型的测试应该有更大的裕量（至少 400%）。调整选项包括

  • 使测试更快。

  • 如果可以接受在减少的平台集上运行测试，则将测试标记为 slow。

  • 如果可以接受只偶尔运行测试，则将测试标记为 xslow。

  • 拆分测试或对其进行参数化，并可能将其中一部分标记为 slow。请注意，这不会减少总测试持续时间，因此其他选项更受欢迎。

  • 对于真正关键的不可避免地很慢的测试，请使用 pytest.mark.fail_slow 添加例外。

有关在本地使用 slow 测试的更多信息，请参阅 在本地运行 SciPy 测试。

轮子构建#

SciPy 发布版以及 *夜间* 构建的轮子是使用 cibuildwheel 在一个 Github Action 中构建的。该 Action 在以下情况下运行

  • 当提交消息包含文本 [wheel build] 时

  • 每周按计划运行一次

  • 当手动启动时。

  • 当有推送到存储库的提交，其 github 引用以 refs/tags/v 开头（并且不以 dev0 结尾）时

该 Action 不会在 SciPy 主存储库的分支上运行。创建的轮子作为与 Action 成功运行相关的工件提供。当 Action 按计划运行或手动启动时，轮子将上传到 *scientific-python-nightly-wheels* 存储库。

不建议您自己使用 cibuildwheel 构建 scipy 轮子，因为它会自动安装 gfortran 编译器和各种其他依赖项。相反，可以使用隔离的 Docker 容器来构建 Linux 轮子。

本页内容