持续集成

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

注意

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

工作流程

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

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

日志可能很长，但您始终可以找到构建/测试未通过检查的原因。只需点击 Details 即可访问日志。

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

GitHub Actions

• Lint: PEP8 和代码风格

• Windows Tests: Windows 测试套件运行

• Linux Tests: Linux 测试套件运行

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

• Wheels builder: 为 SciPy 版本以及 *nightly* 版本构建轮子。

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

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

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

• Array API: 测试 Array API 支持

测试套件在 GitHub Actions 和其他平台上运行，涵盖了一系列测试/环境条件：Python 和 NumPy 版本（从最低支持版本到 nightly 版本）、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]

轮子构建

SciPy 版本和 * nightly * 构建的轮子是使用 cibuildwheel 在 Github Action 中构建的。该操作运行

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

• 每周按计划运行一次

• 当手动启动时。

• 当对存储库进行推送，并且 github 引用以 refs/tags/v 开头（并且不以 dev0 结尾）时

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

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