Перейти к содержанию

Разработка

Документы (OpenSpec)

Требования — в формате OpenSpec:

  • openspec/project.md — назначение, принцип, технологии, соглашения, ограничения платформы
  • openspec/specs/ — действующие требования со сценариями по областям: сбор изменений, статика, пробы компиляции, запросы, сборка копии ИБ, раннер, сценарии, формы, сводка, CI, контрольные дефекты, формат EDT, архитектура, консоль ИБ, анализ ТЖ

Новое поведение — сначала изменение OpenSpec (openspec/changes/<изменение>/: proposal, design, tasks, дельты требований), openspec validate <изменение> --strict, затем код.

Код

  • adding-a-check.md — как добавить проверку: исполнитель, правило статики, реестры
  • findings.md — справочник кодов находок (тест FindingsDocTest следит, что описан каждый код)
  • img/README.md — как пересобрать картинки README

Тесты: python -m unittest discover -s tests из корня (с PYTHONPATH=src). Тесты на внешних программах и копии ИБ идут только при заданных переменных OTK_TEST_* (путь к BSL LS, клон с историей, справка платформы), без них пропускаются.

CI

.github/workflows/ci.yml — на каждый push в master и запрос на слияние:

  • lint — ruff check src tests, mypy (типы на границах пакета) и openspec validate --all --strict;
  • tests — юнит-тесты на Windows и Linux, Python 3.11 и 3.14; платформа 1С не нужна;
  • package — сборка sdist и колеса, установка колеса в чистое окружение, otk --version и данные пакета. Собранное — артефакт dist запуска.

Пробы с платформой 1С (копия ИБ, Конфигуратор, YAxUnit) на облачных раннерах не запускаются: их проверяют otk controls на своём стенде (commands.md, comparison.md).

Метки репозитория задаёт .github/labels.yml (задание labels синхронизирует их при изменении файла), обновления действий CI предлагает Dependabot (.github/dependabot.yml), ревью PR — CodeRabbit (.coderabbit.yaml).

Выпуск

Версия поднимается только при выпуске (SemVer), изменения до него копятся в разделе «Не выпущено» CHANGELOG.md. Между выпусками в master — версия разработки X.Y.(Z+1).dev0: установка из master (pip install "git+https://github.com/cmapnep-tools/otk-1c@master") отличается от выпуска в otk --version и в поле version сводки.

Что выпускать — по меткам PR в разделе «Не выпущено»:

Накопилось Выпуск Когда
только kind/docs, kind/chore (CI, тесты, документация) не выпускается вместе со следующим
kind/bug, kind/false-positive, kind/false-negative, kind/perf Z+1 вскоре после слияния: ошибку пользователя — в тот же или на следующий день, исправления одного дня — одним выпуском
kind/feature Y+1 когда готов набор возможностей (задача или веха)
несовместимое изменение контракта X+1 только с решением сопровождающего

Несколько меток в накопленном — старшая строка таблицы: X+1 > Y+1 > Z+1 (исправления едут в том же выпуске). После слияния PR, дающего выпуск, сопровождающему предлагается выпуск с номером; без его согласия выпуска нет.

  1. PR: раздел «Не выпущено» → ## [X.Y.Z] - ГГГГ-ММ-ДД (и пустой «Не выпущено» над ним), версия X.Y.Z в pyproject.toml и src/otk_1c/__init__.py.
  2. После слияния — тег на коммит master: git tag -a vX.Y.Z -m "ОТК X.Y.Z", git push origin vX.Y.Z.
  3. Задание release (.github/workflows/release.yml) сверяет тег с версией и CHANGELOG, собирает пакет, публикует его на PyPI (окружение pypi с подтверждением сопровождающего) и создаёт GitHub Release с колесом и заметками по меткам PR (.github/release.yml).
  4. Следом PR: версия X.Y.(Z+1).dev0 в тех же двух файлах.

Исправления выходят для последней минорной версии; ветка release/X.Y.x — только когда нужно исправить старую.