CI

В любой системе CI ОТК — один шаг: otk ci gate на запрос на слияние и otk ci designer-check — проверка всех модулей Конфигуратором по метке, ночью или вручную. Коды выхода задают статус задания: 0 — зелёное, 1 — найдены ошибки, 2 — сбой окружения (нет платформы, база занята, отрицательный контроль не сработал). Своей обвязки вокруг шага не нужно: базовую ревизию ОТК берёт из переменных CI, артефакты (сводка, JUnit, problems.txt, SARIF) складывает в каталог --artifacts, его забирает сама система CI.

Шаблоны

Система	Шаблон	Куда положить	Артефакты
Forgejo, Gitea Actions	forgejo/otk-gate.yml, forgejo/otk-designer-check.yml	.forgejo/workflows/ (Gitea — .gitea/workflows/)	загружает сама ОТК по протоколу upload-artifact v3 (проверено на Forgejo): раннеру не нужен node
GitHub Actions	github/otk-gate.yml, github/otk-designer-check.yml	.github/workflows/	actions/upload-artifact@v4
GitLab CI	gitlab/otk.gitlab-ci.yml	.gitlab-ci.yml или include	artifacts, отчёт junit — в запросе на слияние
Jenkins	jenkins/Jenkinsfile	Jenkinsfile (Multibranch Pipeline)	archiveArtifacts, junit

Раннер (агент) — свой, не облачный: на нём установлены платформа 1С, Python 3.11+ и ОТК (python -m pip install otk-1c), лежат своя файловая копия ИБ и каталог прогонов. Они живут между запусками: ОТК грузит в копию только изменённое. Первый запуск — полная загрузка выгрузки. На Linux-раннере всё так же, X-сервер для Конфигуратора и клиента ОТК поднимает сама (linux.md). Раннер, запущенный службой Windows, требует дополнительную лицензию 1С (licensing.md).

Машинные пути задание передаёт переменными OTK_* (IB, USER, PASSWORD, PLATFORM, YAXUNIT, BSLLS, RUN_DIR; полный список — «Настройки»); они, как и везде, важнее otk.toml и otk.local.toml, в файлы каталога проекта ОТК их не пишет. Пароль — секрет системы CI. В шаблонах стенд раннера задаётся одной переменной OTK_HOME (копии ИБ, прогоны, YAxUnit, BSL LS), остальные пути строятся от неё; другая раскладка — задайте пути по отдельности.

База gate — целевая ветка запроса: GITHUB_BASE_REF (GitHub, Forgejo, Gitea), CI_MERGE_REQUEST_TARGET_BRANCH_NAME (GitLab), CHANGE_TARGET (Jenkins). GitLab клонирует только ветку запроса с неполной историей, Jenkins — часто без целевой ветки: ОТК догружает недостающее сама. Не запрос на слияние (push, расписание) — база задаётся явно: --base origin/<ветка>, иначе код 2.

Проверка всех модулей Конфигуратором

• otk designer-check — проверка всех модулей Конфигуратором по метке PR otk-designer-check, ночью и вручную. Перед ней отрицательный контроль: заведомая ошибка обязана найтись, иначе задание падает с «проверка Конфигуратором не работает». Основной вариант — своя маленькая ИБ контроля в кэше пользователя (одна на версию платформы, создаётся сама за ~10 с): ошибка в модуле конфигурации и в модуле расширения, /CheckModules -Server без и с -Extension — ~2 с. ИБ контроля не создаётся (лицензия) или не сработала — ошибка грузится в серверный общий модуль копии и должна найтись самой проверкой всех модулей (копия на поддержке без права изменения при этом снимается с поддержки — копия своя). Режимы — по свойствам конфигурации (обычное приложение — если это основной режим запуска или ordinaryApplication = true); явные modes проверяются: неизвестный ключ Конфигуратор молча пропускает, а без режима отвечает «ошибок нет», ничего не проверив, — поэтому это ошибка настройки. Типовые конфигурации проверку всех модулей без ошибок обычно не проходят, поэтому сверка идёт с базовой линией — otk-designer-check.baseline.json в репозитории (otk designer-check --update-baseline): красным делают только новые ошибки.
• otk ci gate --designer — то же в задании gate: после проб — контроль и проверка всех модулей в той же копии ИБ, базовая линия та же. Новые ошибки — находки шага designer (в той же строке, что ошибка другой проверки, — её источник: «найдено: статика (…), полная проверка Конфигуратором (сервер)»), одна сводка, один JUnit/Problems и код выхода; контроль не сработал или вывод Конфигуратора не разобран — код 2. Только своя копия ИБ (environment.ib), не рабочая база; минуты на отраслевой конфигурации, дольше на ERP — режим для CI, не для хука pre-push.

Что ОТК заменяет в вашем CI

ОТК не добавляет к конвейеру ещё один шаг, а забирает часть существующих. «Заменяет» здесь — только там, где это подтверждено контрольными дефектами (vs-designer.md, vs-analyzers.md) и замерами пилота (pilot.md); в остальных строках ОТК встраивается или не участвует.

Шаг типового конвейера	Чем обычно делают	С ОТК
Синтаксический контроль на каждый запрос	/CheckModules по всей конфигурации, vanessa-runner (vrunner syntax-check, в новых версиях vrunner validate syntax-check)	заменяет на каждом запросе: gate проверяет изменённое — все контрольные дефекты, которые ловит /CheckModules, и сверх того запросы, открытие форм, методы новее режима совместимости. Проверка всех модулей остаётся страховкой по метке или ночью (designer-check)
Загрузка исходников в ИБ для проверки	vanessa-runner, ibcmd, /LoadConfigFromFiles	заменяет: gate сам загружает изменённое в свою копию ИБ (частичная загрузка). Сборку поставки (.cf, .cfe для выпуска) ОТК не делает — этот шаг остаётся
Статический анализ	BSL Language Server, SonarQube	встраивается: BSL LS или bsl-analyzer работают внутри gate, в сводку попадают только новые замечания по правке. Дашборд SonarQube по всему коду остаётся
Открытие форм	дымовые тесты Vanessa-ADD, Vanessa Automation	встраивается: проба открывает изменённые формы в копии ИБ (исключение и зависание при открытии ловятся). Сценарные тесты не заменяет
Юнит-тесты	YAxUnit	встраивается: тесты YAxUnit запускаются в той же копии ИБ, результат — в той же сводке
Проверка проекта EDT	1cedtcli	не заменяет: ОТК читает проект EDT, но проверку самого EDT не повторяет (edt.md)

До и после

Проект-расширение на двух отраслевых конфигурациях, две недели в CI рядом с /CheckModules (pilot.md, 105 проверок, ни одного случая «ОТК зелёный — Конфигуратор красный»):

	До: проверка всех модулей на каждый запрос	После: otk ci gate на каждый запрос
Время на запрос в отраслевой конфигурации	12 мин (медиана), до 21 мин	1 мин 53 с: статика и пробы изменённого
Что ловится	ошибки компиляции	ошибки компиляции и то, чего она не видит: опечатки в полях запросов, исключения и зависания при открытии форм, лишний параметр в вызове, методы новее режима совместимости
Проверка всех модулей	на каждый запрос	по метке, ночью или при слиянии — designer-check

На маленьком проекте Конфигуратор быстрее (расширение — 5 с против 53 с у ОТК): там ОТК окупается не временем, а проверками сверх компиляции. Повторить на своей машине — демо-проект otk-1c-demo: otk controls --parity вносит каждый контрольный дефект и показывает, кто его поймал (vs-designer.md).