Интеграции

Хук pre-push

otk hook install пишет pre-push в каталог хуков репозитория (учитывает core.hooksPath), чужой хук без --force не трогает. Перед push для каждой ветки — gate по отправляемому диапазону (новая ветка — от merge-base с [hook] base); код ≠ 0 отменяет push. Обход — git push --no-verify. Хук запоминает Python и путь к пакету, из которых установлен.

[hook] mode: "full" (по умолчанию) — полная проверка в копии ИБ или рабочей базе (environment.connection); "static" — только статика, секунды: удобно, когда полная проверка идёт в CI на PR. infraFail = "warn" — не блокировать push, если проверка не смогла начаться (например, рабочая база открыта в Конфигураторе).

Журнал срабатываний: каждый запуск хука pre-push и otk pt дописывает строку в <runDir>/history.jsonl (общий для репозиториев): время, источник (hook/pt), действие, команда Platform Tools, репозиторий, код выхода, длительность, версия ОТК. Больше 5 МБ — прежний журнал переименовывается в history.1.jsonl.

Рабочая база вместо копии

Держать копию большой конфигурации только для проверок накладно (копия ERP — больше 5 ГБ), а без удалённого CI проверять приходится там, где работает разработчик. environment.connection = "/F<каталог>" (или "/S<сервер>\\<база>") вместо environment.ib — полная проверка в этой базе, после которой база возвращается к прежнему виду:

• расширение проекта: текущее сохраняется в .cfe, загружается проверяемая редакция, после проверки — возвращается (или удаляется, если его не было);
• основная конфигурация по умолчанию считается уже загруженной (полная загрузка ERP на каждую проверку — долго); loadProject = true — загружать проверяемую редакцию (без возврата). Если основная конфигурация не применена к БД (КонфигурацияИзменена()), пробы исполнили бы прежний код: ОТК базу не обновляет, пробы исполнения — «не проверено» с советом обновить конфигурацию БД (расширенная проверка и статика работают);
• инструменты (YAxUnit, расширение проб otk, тестовые расширения) ставятся на время проверки и удаляются; одноимённые, которые уже были в базе (например, YAxUnit из Platform Tools), возвращаются как были. keepTools = true — оставить, следующая проверка быстрее;
• база занята (открыт Конфигуратор или сеанс) — проверка не начинается (код 2), база не трогается.

Возврат выполняется и при сбое проверки; если вернуть не удалось, сводка говорит об этом прямо и называет файл .cfe, из которого восстановить расширение вручную. Проверено на файловой базе; для серверной (/S…) режим пока не проверялся: снятие безопасного режима с инструментов (ibcmd или внешнее соединение) и чтение журнала регистрации рассчитаны на файловую базу.

VS Code «1C: Platform Tools»

Проверка расширения при загрузке из 1C: Platform Tools идёт в той базе, куда оно загружается (копии нужной базы может не быть, а большую копировать дорого):

Команда Platform Tools	До	После
Загрузить из исходного кода, из objlist.txt	pt pre: сохранить расширение базы в .cfe	pt post: статика + Конфигуратор в базе (+ пробы COM и разбор запросов, если загрузка с обновлением БД); ошибки — откат
Загрузить из *.cfe	pt pre	pt post --no-static: Конфигуратор в базе; ошибки — откат
Обновить расширения в ИБ, Выгрузить в *.cfe	pt check: Конфигуратор в базе; ошибки — команда отменяется	—
Собрать *.cfe из исходного кода	pt static: статика исходников; ошибки — сборка отменяется	—
Основная конфигурация: Загрузить конфигурацию из исходного кода, Загрузить изменения (git diff), Загрузить из objlist.txt, Обновить конфигурацию в ИБ	pt cf-pre: статика изменённых модулей рабочего дерева; ошибки — команда не выполняется	pt cf-post: расширенная проверка изменённых общих модулей (временное расширение без применения к БД) и, если БД обновлена, пробы COM; ошибки — сводка, без отката

Для основной конфигурации главное — статика до загрузки: кривой код не тратит время на загрузку, обновление БД и запуск. Откатывать основную конфигурацию после загрузки дорого (сохранить и вернуть конфигурацию вроде ERP — минуты), поэтому после загрузки — только сообщение; полная проверка Конфигуратором /CheckModules для большой конфигурации — минуты или часы, её место — otk designer-check и CI. У проекта-расширения команды основной конфигурации к его коду не относятся — хук пропускает их с сообщением.

Проверка Конфигуратором — все режимы и -ExtendedModulesCheck для расширения. Пробы COM и разбор запросов (опечатки в полях и таблицах запросов Конфигуратор не ловит) идут через внешнее соединение с целевой базой — только чтение, в базу ничего не ставится; они возможны, лишь когда расширение применено к БД (загрузка с обновлением). Откат — возврат сохранённого расширения (или его удаление, если его не было), при загрузке с обновлением БД — и обновление БД. Не удалось сохранить расширение — загрузка отменяется: откатывать было бы не к чему. Не удался сам откат — код 2 (не 1) и в сводке «ОТКАТ НЕ УДАЛСЯ» с путём к сохранённому .cfe: базу возвращают вручную. При ошибках сводка открывается в VS Code. Если сама команда загрузки завершилась ошибкой (например, при загрузке с обновлением БД не стартовал сеанс с новым расширением), Platform Tools вызывает onError вместо post — pt post --on-error восстанавливает расширение всегда. vanessa-runner 3 обновляет БД при загрузке по умолчанию («Только загрузить» — --no-update-db): откат тогда обновляет и БД.

Базу и вход Platform Tools передаёт хуку сам (VRUNNER_ARGS: профиль --settings), настройки проекта — в otk.toml (source, parent, extension). Образец .1cpt/hooks.json — platform-tools/hooks.json; ОТК должен быть доступен как python -m otk_1c (pip install otk-1c). Пробы в клиенте (YAxUnit) в рабочую базу не ставятся.