Для кого: программисты и DevOps-инженеры 1С, которые переносят сборку и проверку конфигурации в консоль или в CI.
В vanessa-runner 3.0 команды сгруппированы заново (infobase, validate, test, cf, cfe, run), а вызовы версии 2.x (init-dev, load, vanessa) на 3.0.2 завершаются ошибкой. Цепочка infobase init, validate syntax-check, infobase dump-dt прогнана на платформе 8.3.27.2130 с кодами возврата и отчётом JUnit. Запуск тестов проверен только по справке команд.
Большинство инструкций по vanessa-runner написаны для версий 1.x и 2.x. В версии 3.0 команды сгруппированы иначе, и старые вызовы перестали работать. На vanessa-runner 3.0.2 команды vrunner init-dev, vrunner load, vrunner vanessa и vrunner run --mode config завершаются ошибкой «Ошибка чтения параметров команды». Ниже описаны команды, которые запускались на этой версии, с кодами возврата и временем.
📥 Установка
Для vanessa-runner 3.0 нужен OneScript 2.0.0 или новее (требование из README проекта). Пакет ставится менеджером OPM:
opm install vanessa-runner
Пакет называется vanessa-runner. Попытка поставить пакет vrunner заканчивается сообщением «Пакет не найден». Исполняемый файл называется vrunner.
Глобальная установка кладёт vrunner в каталог библиотек OneScript. Локальная (opm install -l vanessa-runner) создаёт в текущем каталоге oscript_modules\bin\vrunner.bat; этот каталог добавляют в PATH на время работы. Проверка версии:
vrunner --version 3.0.2
📋 Какие команды есть в версии 3.0
Команды образуют группы. Список получен из vrunner --help и vrunner <группа> --help:
| Группа | Подкоманды |
|---|---|
run |
enterprise, designer |
infobase |
init, update, restore-dt, dump-dt, create-user, scheduled-job, lock-resources, extensions |
cf |
load, unload, compile, decompile, compare, merge, make-dist, convert, vendor-update |
cfe |
load, unload, compile, decompile, compare, convert |
epf |
compile, decompile, convert |
test |
vanessa, xunit, yaxunit |
validate |
syntax-check, edt |
repo |
create, bind, load, commit, lock, unlock и другие операции с хранилищем |
cluster |
session, jobs, info, create, remove |
Соответствие старым командам, которое даёт README проекта: vrunner vanessa стал vrunner test vanessa, vrunner updatedb стал vrunner infobase update, vrunner syntax-check стал vrunner validate syntax-check. Переменные окружения переименованы с префикса RUNNER_ на VRUNNER_.
💻 Стенд для проверки
Исходники: пустая конфигурация, выгруженная платформой (/DumpConfigToFiles), и один общий модуль ОбщегоНазначенияПример с функцией:
Платформа 8.3.27.2130 (x86), файловая база, Windows 11. Время в статье получено на такой малой конфигурации и показывает расходы на запуск платформы. Скорость на конфигурации в тысячи объектов нужно мерять отдельно.
🧱 Создать базу из исходников
vrunner infobase init --src src --ibconnection "/FC:\work\ib-test\ib"
Команда создала файловую базу, загрузила конфигурацию из каталога XML и обновила конфигурацию базы данных. Ушло 23,8 с, код возврата 0. Формат исходников (XML Конфигуратора или EDT) определяется автоматически, ключ --src-format задаёт его явно. Для расширений есть ключ --ext, его можно указать несколько раз. В справке команды есть и ключ --ibcmd (работать через утилиту ibcmd вместо Конфигуратора): в нашей установке платформы ibcmd не было, ключ не запускался.
🩺 Проверить синтаксис и получить отчёт
vrunner validate syntax-check --mode Server --mode ThinClient --report-format junit --report-path build\junit.xml
На корректном модуле команда отработала за 17,9 с с кодом 0, в отчёте JUnit один тест без ошибок. Затем в модуль добавлена ошибка Возврат А + ;. Результат:
ПРЕДУПРЕЖДЕНИЕ - {ОбщийМодуль.ОбщегоНазначенияПример.Модуль(2,13)}: Ошибка в выражении Возврат А +<<?>> ; (Проверка: Сервер)
Код возврата 1, в отчёте JUnit failures="1" с той же строкой. Такой код и такой отчёт понимает любой CI.
Режимы проверки перечислены в справке vrunner validate syntax-check --help: ThinClient, WebClient, Server, ExternalConnection, ThickClientManagedApplication и другие, включая UnreferenceProcedures, EmptyHandlers, CheckUseModality. Ключ --mode можно указывать несколько раз. --target выбирает, что проверять: main, AllExtensions или расширение по имени.
Важное наблюдение по порядку шагов. Команда infobase update загрузила модуль с синтаксической ошибкой без единого предупреждения и завершилась с кодом 0 (26,9 с). Синтаксис проверяет только validate syntax-check, поэтому в цепочке он должен идти после каждой загрузки.
Замер автора: Windows 11, платформа 8.3.27.2130 (x86), файловая база, конфигурация из одного общего модуля, одна серия. Время показывает расходы на запуск платформы, а не скорость на большой конфигурации.
🔧 Настройки в файле и переменные окружения
Повторять --ibconnection в каждой команде не нужно. Первый вариант - файл autumn-properties.json в текущем каталоге:
С таким файлом команда vrunner validate syntax-check без единого ключа выполнила проверку и записала отчёт по указанному пути (18,3 с). Второй вариант - переменные окружения: VRUNNER_IBCONNECTION задаёт строку подключения для всех команд сессии, в справке команд перед каждой переменной стоит env $VRUNNER_.... Проверка с одной переменной и без файла прошла с кодом 0. Путь к другому файлу настроек задаёт ключ --settings.
Пароли (--db-user, --db-pwd, VRUNNER_DBPWD) лучше передавать через секреты CI, в файл настроек они не коммитятся.
💾 Выгрузка и загрузка dt, выгрузка cf
vrunner infobase dump-dt --ibconnection "/FC:\work\ib-test\ib" build\ib1.dt vrunner cf unload --ibconnection "/FC:\work\ib-test\ib" build\ib1.cf vrunner infobase restore-dt --ibconnection "/FC:\work\ib-test\ib2" build\ib1.dt
Выгрузка dt заняла 13,1 с (файл 29 805 байт), выгрузка cf 12,8 с (76 860 байт), загрузка dt в новый путь 13,3 с; во всех случаях база ib2 создалась. Одна грабля: путь к файлу передаётся аргументом и должен стоять после всех ключей. Вызов vrunner infobase dump-dt build\ib1.dt --ibconnection ... даёт «Ошибка чтения параметров команды». Так же с переменной окружения: vrunner infobase dump-dt build\ib1.dt работает, ключи после аргумента - нет.
🔗 Цепочка целиком
Скрипт из трёх шагов: создать базу, проверить синтаксис, выгрузить dt. Строка подключения передаётся через окружение, каждый шаг проверяет код возврата и печатает время:
Прогон на стенде: syntax-check 17,4 с, dump-dt 12,7 с, код 0. Этот же набор команд переносится в GitLab CI или GitHub Actions при условии, что на раннере установлены платформа 1С и OneScript. Сам CI-файл в этой проверке не запускался.
🧪 Тесты: что проверено и что нет
Группа test содержит vanessa, xunit и yaxunit. По справке vrunner test vanessa --help команда принимает путь к фичам (--feature-path, макрос $addRoot указывает на каталог Vanessa-ADD), теги (--tags-filter, --tags-ignore), файл настроек Vanessa (--vanessasettings), формат и путь отчёта (--report-format, --report-path) и сбор покрытия (--coverage-report с форматами generic, cobertura, clover). Запуск тестов на платформе в этой проверке не выполнялся: для него нужны Vanessa-ADD и тестовый клиент. Ключи в этом разделе перечислены по справке, работа команд не подтверждена.
🚧 Что не подтверждено
- Скорость на большой конфигурации. Замеры сделаны на одном общем модуле.
- Ключ
--ibcmd, серверные базы (/S), работа на Linux,run enterprise,repo,cfe,test. - Инкрементальная загрузка (
--increment) на двух повторах не дала выигрыша:infobase updateзанимал 25,9 и 26,9 с при 23,8 с на создание базы с нуля. На конфигурации из одного модуля это ожидаемо, на большой нужен отдельный замер.
🏁 Итог
Цепочка из трёх команд infobase init, validate syntax-check и infobase dump-dt работает на vanessa-runner 3.0.2 и платформе 8.3.27.2130, возвращает коды возврата и отчёт JUnit. Если вы пользуетесь vrunner в CI, проверьте, не остались ли в скриптах команды версии 2.x: они падают с одной и той же ошибкой чтения параметров. Напишите в комментариях, какие ещё команды vrunner стоит проверить на платформе.
Вступайте в нашу телеграмм-группу Инфостарт