Непрерывная интеграция#

Непрерывная интеграция (CI) является частью нашего процесса разработки и гарантирует, что каждый фрагмент кода или документации, вносимый в SciPy, работает и не имеет непредвиденных эффектов.

Примечание

Перед отправкой или обновлением вашего PR, пожалуйста, убедитесь, что вы протестировали ваши изменения локально. Смотрите Контрольный список перед отправкой PR и Локальный запуск тестов SciPy.

Рабочие процессы#

Мы запускаем более 20 различных рабочих процессов с разными версиями зависимостей, разными архитектурами и т.д. PR должен пройти все эти проверки перед слиянием, чтобы обеспечить устойчивое состояние проекта.

Помимо модульных тестов, также проверяются документация и примеры в docstrings. Это распространённые проблемные места, так как Sphinx и doctests имеют очень строгие правила. Эти аспекты очень важны, поскольку документация и примеры являются элементами, с которыми взаимодействуют пользователи. Гарантирует, что эти элементы правильно отображаются.

Логи могут быть длинными, но вы всегда узнаете, почему ваша сборка/тест не прошёл проверку. Просто нажмите на Details для доступа к журналам.

Ниже приведен список всех различных рабочих процессов в использовании. Они сгруппированы по провайдерам ресурсов CI.

GitHub Actions#

  • Lint: PEP8 и стиль кода

  • Windows Tests: тестовый набор запускается для Windows

  • Linux Tests: тестовый набор запускается для Linux

  • macOS Tests: тестовый набор запускается для macOS (x86_64)

  • Wheels builder: собирает wheels для релизов SciPy, а также для nightly сборки.

  • 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: тесты из примеров и бенчмарков

Пропуск#

Будучи проектом с открытым исходным кодом, у нас есть доступ к квоте ресурсов CI. В конечном счете, ресурсы ограничены, и мы должны использовать их с осторожностью. Поэтому мы просим вас проверить ваши изменения локально перед отправкой.

В зависимости от предлагаемого изменения, вы можете пропустить часть проверок. На усмотрение сопровождающего будет повторный запуск некоторых тестов перед интеграцией.

Пропуск CI может быть достигнут добавлением специального текста в сообщение коммита:

  • [skip actions]: пропустит GitHub Actions

  • [skip circle]: пропустит CircleCI

  • [docs only]: будет пропущено все, кроме проверки CircleCI и линтер

  • [lint only]: будет пропущено все, кроме линтер

  • [skip ci]: будет пропущено все CI

Конечно, вы можете комбинировать их, чтобы пропустить несколько рабочих процессов.

Эта информация о пропуске должна быть размещена на новой строке. В этом примере мы просто обновили .rst файл в документации и запрос пропустить все, кроме соответствующих проверок документации (пропустить рабочие процессы 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, пожалуйста, скорректируйте тест, чтобы он не проваливался в будущем. Даже если новые тесты не проваливаются, пожалуйста, проверьте детали workflow, которые включают 'fail slow' в своем названии, перед слиянием PR. Они содержат списки тестов, которые приближаются (или превысили) свой лимит времени. Из-за вариаций во времени выполнения тесты со временем выполнения, близким к порогу, должны быть скорректированы, чтобы избежать провала, даже если их время выполнения увеличится на 50%; типичные тесты должны иметь гораздо больший запас (не менее 400%). Варианты корректировки включают:

  • Ускорение теста.

  • Помечая тест как slow, если допустимо запускать тест на сокращённом наборе платформ.

  • Помечая тест как xslow, если допустимо запускать тест только время от времени.

  • Разделение теста или его параметризация, и возможная пометка частей как медленных. Обратите внимание, что это не уменьшает общую продолжительность теста, поэтому предпочтительны другие варианты.

  • Для действительно критических тестов, которые неизбежно медленные, добавьте исключение с помощью pytest.mark.fail_slow.

См. Локальный запуск тестов SciPy для получения дополнительной информации о работе с медленными тестами локально.

Сборки Wheel#

Wheels для релизов SciPy и *nightly* сборки создаются с использованием cibuildwheel в Github ActionДействие выполняется:

  • когда сообщение коммита содержит текст [wheel build]

  • по расписанию раз в неделю

  • когда он запускается вручную.

  • когда происходит push в репозиторий со ссылкой на GitHub, начинающейся с refs/tags/v (и не заканчивающийся на dev0)

будет установлено в 1, если было 0. *scientific-python-nightly-wheels* репозиторий.

Не рекомендуется использовать cibuildwheel для сборки колес scipy на вашей собственной системе, так как он автоматически установит компиляторы gfortran и различные другие зависимости. Вместо этого можно использовать изолированный контейнер Docker для сборки колес Linux.