Ctrl+K

持續整合#

持續整合 (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 發行版以及每夜建置建置 wheels。

  • Check the rendered docs here!：文件的即時預覽

  • prerelease_deps_coverage_64bit_blas：使用預先發布版本的依賴套件並檢查覆蓋率

  • gcc-9：使用最低支援版本的 GCC 建置，安裝 wheel，然後使用 python -OO 運行測試套件

  • Array API：測試 Array API 支援

測試套件在 GitHub Actions 上運行，其他平台涵蓋一系列測試/環境條件：Python 和 NumPy 版本（從最低支援到每夜建置）、32 位元與 64 位元、不同的編譯器等等 - 詳細資訊請參閱 .yml 配置文件。

CircleCI#

  • build_docs：建置文件

  • build_scipy

  • run_benchmarks：驗證變更如何影響效能

  • refguide_check：來自範例和基準測試的 doctest

CirrusCI#

  • Tests：特定架構（如 musllinux、 arm、 aarch）的測試套件

  • Wheels：建置和上傳一些 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)，使其具有 10 秒的限制，無論它是否為「快速」或「完整」測試套件的一部分。

如果在 PR 開發期間的任何時候，測試因超出時間限制而失敗，請調整測試以確保它將來不會失敗。即使新測試沒有失敗，也請在 PR 合併之前檢查包含「fail slow」的工作流程的詳細資訊。這些包括接近（或已超過）其時間限制的測試列表。由於執行時間的變化，執行時間接近閾值的測試應進行調整，以避免即使其執行時間增加 50% 也會失敗；典型測試應具有更大的餘裕（至少 400%）。調整選項包括

  • 使測試更快。

  • 如果可以接受在縮減的平台上運行測試，則將測試標記為 slow。

  • 如果可以接受僅偶爾運行測試，則將測試標記為 xslow。

  • 分解測試或參數化測試，並可能將其部分標記為 slow。請注意，這不會減少總測試時間，因此首選其他選項。

  • 對於真正關鍵且不可避免地緩慢的測試，請使用 pytest.mark.fail_slow 新增例外。

有關在本機使用 slow 測試的更多資訊，請參閱 在本機執行 SciPy 測試。

Wheel 建置#

SciPy 發行版和 每夜 建置的 wheels 是使用 cibuildwheel 在 Github Action 中建置的。Action 在以下情況下運行

  • 當提交訊息包含文字 [wheel build] 時

  • 每週一次的排程基礎上

  • 手動啟動時。

  • 當有 push 到儲存庫，且 GitHub 參考以 refs/tags/v 開頭（且不以 dev0 結尾）時

該 action 不會在主 SciPy 儲存庫的分支上運行。建立的 wheels 可作為與 Action 成功運行相關聯的 artifacts 使用。當 Action 在排程上運行或手動啟動時，wheels 會上傳到 scientific-python-nightly-wheels 儲存庫。

不建議在您自己的系統上使用 cibuildwheel 建置 scipy wheels，因為它會自動安裝 gfortran 編譯器和各種其他依賴套件。相反地，可以使用隔離的 Docker 容器來建置 Linux wheels。

在本頁中