Можно ли проверить код 1С на ошибки, если 1С не установлена? Опыт со скриптом в Docker

В статьях про автоматическую проверку 1С обычно рисуют такую схему: контейнер Docker, в нём скрипт, на выходе отчёт, который GitLab показывает в запросе на слияние. Скрипт из моего первого варианта этой статьи делал ровно это и всегда завершался с кодом 0, то есть «всё в порядке». Я подала ему одиннадцать модулей, семь из которых сама 1С отвергла, и он пропустил все одиннадцать. Он проверял только одно: файл не пустой.

Ниже расскажу, как это выяснилось, что умеет переписанный скрипт, как запускать его в Docker без доступа к сети и что в любом случае остаётся за самой 1С. Всё прогонялось на этом компьютере 22 октября 2026 года.

Стенд

Самой 1С в образе Docker нет: лицензия и дистрибутив остаются за вами. Контейнер проверяет то, что видно в тексте модуля.

Одиннадцать модулей для проверки

Для проверки я собрала 11 файлов .bsl. Четыре целых: настоящие общие модули «Нано-УТ» (ЦеныУчет, УчетСервер, ФормыСервер, ДокументыСервис). Шесть получены из них одной поломкой: удалён КонецЕсли, КонецПроцедуры, КонецПопытки или КонецЦикла, не закрыта кавычка строки или добавлена лишняя скобка. Один модуль написан без ошибок структуры, но вызывает процедуру НесуществующаяПроцедура().

Скрипт make_corpus.py собирает эти файлы, а make_cf.py добавляет их в копию «Нано-УТ» как общие модули Ok01...Sem01. Конфигуратор загружает конфигурацию в пустую файловую базу и проверяет модули:

1cv8.exe DESIGNER /F <база> /LoadConfigFromFiles <выгрузка> /UpdateDBCfg
1cv8.exe DESIGNER /F <база> /CheckModules -Server -ExternalConnection

Конфигуратор вернул код 101 и указал семь модулей: Bad01...Bad06 и Sem01. Четыре целых модуля замечаний не получили. На чистой «Нано-УТ» без добавленных модулей тот же вызов даёт код 0 и сообщение «Синтаксических ошибок не обнаружено».

Например, для Bad01 1С написала: {ОбщийМодуль.Bad01.Модуль(15,1)}: Ожидается ключевое слово 'КонецЕсли'. Для Sem01: Процедура или функция с указанным именем не определена (НесуществующаяПроцедура).

Что делал скрипт из первого варианта

Скрипт искал файлы *.epf, *.erf и *.bsl, читал каждый, сообщал об ошибке только для файла нулевой длины и печатал [OK] для всех остальных. Вся проверка:

1
2
3

content = f.read_bytes()
if len(content) == 0:
    raise ValueError("Пустой файл")

Тесты verify.py к нему проверяли, что файлы Docker на месте, что на одном целом модуле скрипт возвращает 0 и что корневой элемент отчёта называется testsuite. Скрипт не мог провалить ни один тест, потому что содержимое файлов не читал. Вот его ответ на мои 11 модулей:

Из 11 строк [OK] семь относятся к модулям, которые 1С отвергла. Для GitLab такой отчёт означает зелёный статус проверки.

Новый скрипт

Новый headless_runner.py читает только .bsl и просматривает текст по символам. Он запоминает открытые блоки (Процедура, Функция, Если, Цикл, Попытка и их английские написания), считает скобки, следит за строковыми литералами (в том числе многострочными, где строки начинаются с |) и за парой #Если/#КонецЕсли. Строчные комментарии // пропускаются. Основной фрагмент:

1
2
3
4
5
6
7
8

if w in OPEN:
    stack.append((OPEN[w], no))
elif w in CLOSE:
    if stack and stack[-1][0] == w:
        stack.pop()
    else:
        want = stack[-1][0] if stack else "ничего"
        errors.append((no, f"{m.group(0)} не соответствует открытому блоку (ожидалось: {want})"))

Ошибки каждого файла скрипт записывает в отчёт для систем непрерывной интеграции (формат JUnit XML, его понимают GitLab и GitHub Actions) с номерами строк. Код завершения 0 означает «все модули целые», 1 - «есть ошибки», 2 - «не найдено ни одного .bsl». Пустой каталог считается ошибкой: иначе неверный путь в настройках конвейера давал бы зелёный статус. Бинарные .epf и .erf скрипт пропускает и сообщает, сколько их было.

Запуск в Docker без сети

1
2
3
4
5
6

FROM python:3.12-slim
ENV LANG=C.UTF-8 PYTHONUTF8=1 PYTHONDONTWRITEBYTECODE=1
WORKDIR /workspace
COPY headless_runner.py /usr/local/bin/headless_runner.py
ENTRYPOINT ["python", "/usr/local/bin/headless_runner.py"]
CMD ["--scan-dir", "/workspace", "--output-junit", "/reports/junit.xml"]

1
2
3
4
5
6
7
8
9

services:
  runner-1c:
    build: .
    image: bsl-structure-runner:1.0
    network_mode: "none"
    read_only: true
    volumes:
      - ./workspace:/workspace:ro
      - ./reports:/reports:rw

Параметр network_mode: "none" отключает сети у контейнера, read_only: true запрещает запись в его файловую систему, а проверяемые файлы подключены только для чтения. Запись разрешена в одном каталоге, куда попадает отчёт.

Первый вариант тянул Ubuntu 22.04 с xvfb, git, curl и русской локалью. Скрипту из этого нужен только Python: он читает файлы как UTF-8 и ничего не рисует. xvfb (виртуальный экран) понадобился бы клиенту 1С, а 1С в образе нет. Поэтому образ собран на python:3.12-slim.

Защиту проверяет verify.py --docker. Из контейнера без сети попытка соединиться с 1.1.1.1:443 заканчивается ошибкой OSError. Запись в файловую систему контейнера отклоняется. Запуск на примерах с ошибками возвращает код 1. Вот запуск из чистой распаковки архива:

Сравнение с самой 1С

Те же 11 модулей я подала новому скрипту и сравнила его ответы с ответами 1С. Столбцы «Раннер из черновика» и «Раннер версии 2» в таблице - это скрипт из первого варианта и новый скрипт.

Все шесть поломок структуры новый скрипт отклонил, как и 1С. На Bad01 он указывает строки 1, 2 и 15: 1С остановилась на строке 15, где вместо КонецЕсли стоит КонецПроцедуры. Лишние сообщения скрипта о строках 1 и 2 - следствие незакрытых блоков, а первая найденная ошибка совпадает по смыслу.

Одиннадцатый модуль, Sem01, скрипт пропустил, а 1С нет. Скрипт не знает, какие процедуры есть в конфигурации. За самой 1С остаются неверное число параметров, неизвестные свойства и методы, типы значений, доступность вызова на клиенте и на сервере, директивы компиляции. Новый скрипт годится как быстрая первая проверка: он отсеивает поломанные файлы за доли секунды и без лицензии 1С, а полную проверку выполняет Конфигуратор через platform_check.py на компьютере с установленной 1С.

Подключение к GitLab CI

В архиве лежит шаблон gitlab-ci.example.yml: задание запускает образ со скриптом и передаёт GitLab отчёт reports/junit.xml. В GitLab я его не запускала. Проверено другое: скрипт пишет корректный XML с корнем testsuite, атрибутами tests и failures и элементом failure у каждого упавшего модуля.

Что не проверено

• GitLab CI и GitHub Actions: как отчёт выглядит в запросе на слияние, я не воспроизводила.
• 1С для Linux внутри контейнера и запуск Конфигуратора с виртуальным экраном xvfb: Linux-версии 1С у меня нет.
• Бинарные .epf и .erf: скрипт их пропускает.
• Модули с редкими конструкциями препроцессора, Выполнить() со строкой кода, другие версии платформы.
• Скорость на других компьютерах: у меня старый процессор и SATA SSD, на современном железе время прогона будет другим.

Если у вас в конвейере уже есть контейнер с 1С, мне интересно, чем вы отсеиваете поломанные файлы до запуска Конфигуратора и сколько времени это экономит.

Итог

• Скрипт, проверявший только «файл не пустой», пропустил все 11 модулей, включая 7 отвергнутых самой 1С. Зелёный отчёт в конвейере такая проверка не гарантирует.
• Новый скрипт отклонил 6 модулей с поломанной структурой и совпал с 1С на 10 модулях из 11. Он не заменяет /CheckModules: вызов несуществующей процедуры нашла только 1С.
• Контейнер запускается без сети и с файловой системой только для чтения; эти проверки входят в verify.py --docker.

Источники

• Руководство администратора 1С:Предприятия 8.3, раздел 7.4 «Running Designer in batch mode» (ключи /LoadConfigFromFiles, /CheckModules): https://kb.1ci.com/1C_Enterprise_Platform/Guides/Administrator_Guides/1C_Enterprise_8.3.23_Administrator_Guide/Appendix_7._The_parameters_of_the_command_line_to_launch_1C_Enterprise/7.4._Running_Designer_in_batch_mode/
• «Зачем одинэснику docker?», Infostart: //infostart.ru/public/2688032/ - обзор применения Docker в работе 1С-разработчика.
• «1C:SRE-Suite: автоматизируем непрерывную интеграцию (CI) через GitHub Actions», Infostart: //infostart.ru/public/2780378/ - сборочный агент 1С в контейнере.
• «Как проверять код на языке 1С с помощью BSL Language Server», Infostart: //infostart.ru/public/1789716/ - полноценный статический анализ BSL; скрипт из этой статьи его не заменяет.

Файл к статье

Архив docker-bsl-runner-companion.zip (версия 2 от 22.10.2026): headless_runner.py, Dockerfile, docker-compose.yml, verify.py, examples/ (пять небольших модулей), platform_check.py, шаблон gitlab-ci.example.yml, README.md и папка evidence с журналами прогона. Архив распаковывайте в обычную папку вроде C:\work\: docker build из папки OneDrive у меня падал. Проверки verify.py запускаются на любой системе с Python 3.9+, флаг --docker требует Docker, platform_check.py - Windows с 1С 8.3 (python platform_check.py --dump <выгрузка> --exe <путь к 1cv8.exe>).

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S