持续集成#

持续集成 (CI) 是我们开发过程的一部分，确保贡献给 SciPy 的每一段代码或文档都能正常工作，并且不会产生意外的影响。

备注

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

工作流程#

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

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

日志可能会很长，但你总能找出为什么你的构建/测试未能通过检查。只需点击 Details 即可访问日志。

以下是所有不同工作流的列表。它们按CI资源提供者分组。

GitHub Actions#

  • Lint: PEP8 和代码风格

  • Windows 测试: 针对 Windows 的测试套件运行

  • Linux 测试: 针对 Linux 的测试套件运行

  • macOS 测试: 针对 macOS (x86_64) 的测试套件运行

  • Wheels builder: 为 SciPy 发布版本以及 nightly 构建生成轮子。

  • 在这里查看渲染后的文档！: 文档的实时预览

  • 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：

  • [跳过操作]: 将跳过 GitHub Actions

  • [skip circle]: 将跳过 CircleCI

  • [skip cirrus]: 将跳过 CirrusCI

  • [仅文档]: 将跳过 除 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。

  • 分解测试或参数化测试，并可能将部分测试标记为慢速。请注意，这并不会减少总的测试时间，因此优先考虑其他选项。

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

有关在本地处理慢速测试的更多信息，请参阅 在本地运行 SciPy 测试。

Wheel 构建#

SciPy 发布和 *nightly* 构建的轮子是使用 cibuildwheel 在 Github Action 中构建的。该 Action 运行：

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

  • 每周一次按计划进行

  • 当它被手动启动时。

  • 当向仓库推送一个以 refs/tags/v 开头（且不以 dev0 结尾）的 github 引用时

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

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

On this page