Сравнение расширений 1С (.cfe): что меняет расширение

Бинарный .cfe файл расширения 1С в системе контроля версий бесполезен для ревью: git diff покажет только, что файл изменён, без единой строки о том, что именно поменялось. Чтобы сравнить расширения 1С по существу, нужно распаковать оба контейнера, разобрать структуру и сопоставить код, формы и метаданные. Этим занимается CFEDiff, структурный diff расширений в редакции Профессиональная.

TL;DR

.cfe это файл расширения конфигурации 1С, и в бинарном виде он непригоден для ревью: git diff видит только факт изменения. CFEDiff распаковывает два CFE-расширения 1С и выдаёт построчный diff BSL-кода, форм и метаданных. Это действие review_extension инструмента code_review в редакции Профессиональная, плюс CLI mcp-1c-pro review для CI и pre-commit. Базовое чтение .cfe есть уже в Расширенной редакции, структурное сравнение это уровень Профессиональной.

Что такое cfe файл 1С?

.cfe это официальный механизм платформы 1С, расширение конфигурации. Расширения позволяют дорабатывать конфигурацию без снятия её с поддержки.

Штатный механизм платформы умеет сравнивать и объединять конфигурации (основную, конфигурацию базы данных, конфигурацию во внешнем файле, конфигурацию поставщика) вплоть до отдельных реквизитов, табличных частей, форм и модулей. Но это сравнение конфигураций между собой, а не файлов расширений: задачу "сопоставь два .cfe" стандартное сравнение и объединение конфигураций напрямую не решает.

Базовое чтение .cfe (автообнаружение установленных расширений, метка [Расш] в результатах code_search и code_read) доступно уже в редакции Расширенная. Структурное сравнение это уровень редакции Профессиональная, инструмент code_review.

Как сравнить расширения 1С через review_extension?

code_review это консолидированный инструмент Профессиональной редакции с двумя действиями: review_extension (CFEDiff, структурный diff двух версий .cfe) и base_vs_ext (сверка основной конфигурации с расширением).

review_extension заменяет ручной diff и git diff бинарных .cfe. CFEDiff распаковывает оба расширения, разбирает их структуру и выдаёт Markdown-отчёт: у объекта построчно сравнивается не больше одного модуля BSL, а из метаданных объекта читаются только имя и вид.

Как вызвать через MCP-инструмент?

Через MCP-клиент вызывается действие review_extension с путями к двум файлам. Отчёт возвращается прямо в чат.

Как встроить в CI и pre-commit?

Для конвейера и git-хука есть командная строка без MCP-клиента:

mcp-1c-pro review --format markdown -o diff.md base.cfe head.cfe
echo "exit code: $?"

Коды возврата позволяют завязать на результат проверку в CI:

С версии 2.41.0 изменённым объект бывает и тогда, когда его содержимое на вид то же: те же байты иначе разложены по потокам, на одной стороне есть лишний пустой поток или несколько записей контейнера дают объекту один поток с разными байтами. Такое сравнение тоже даёт код 1. Файлы, равные байт в байт, дают 0.

Минимальный workflow GitHub Actions запускает проверку на каждый pull request с изменёнными .cfe. Бинарник mcp-1c-pro для Linux должен быть на раннере до этих шагов, путь к нему записывается в переменную репозитория MCP_1C_PRO_BIN, а ключ лицензии хранится в секрете MCP_1C_LICENSE_KEY. Путь указывайте полный и такой, который не проходит через рабочую копию: её файлы задаёт pull request, и бинарник оттуда получил бы ключ лицензии:

# .github/workflows/cfediff.yml
name: cfediff
on:
  pull_request:
    paths:
      - '**/*.cfe'
permissions:
  contents: read
env:
  MCP_1C_PRO_BIN: ${{ vars.MCP_1C_PRO_BIN }}
jobs:
  diff:
    runs-on: ubuntu-latest
    steps:
      # fetch-depth: 0 нужен, чтобы достать base-версию .cfe из истории;
      # токен в .git/config дальше не нужен, поэтому он не сохраняется
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: activate licence
        env:
          MCP_1C_LICENSE_KEY: ${{ secrets.MCP_1C_LICENSE_KEY }}
        run: |
          "$MCP_1C_PRO_BIN" --activate "$MCP_1C_LICENSE_KEY" < /dev/null
      - name: review changed .cfe
        run: |
          git show "${{ github.event.pull_request.base.sha }}:ext.cfe" > base.cfe
          "$MCP_1C_PRO_BIN" review --format markdown -o diff.md base.cfe ext.cfe < /dev/null

Команда review в шаге последняя, поэтому шаг завершается с её кодом: в таком виде проверка падает и при найденных различиях (1), и при ошибке (2). Код 1 означает и различия, и ошибку во флаге перед файлами: по коду выхода эти случаи не различить, поэтому, если считать код 1 успехом, ошибка во флаге тоже пройдёт незамеченной. Пример сравнивает один файл ext.cfe с его версией по тому же пути в base-ветке: если там его нет, например файл добавлен или переименован в этом PR, base-версии нет, и шаг упадёт. С версии 2.41.0 пустой секрет с ключом шаг активации не пропустит: --activate с пустой строкой или одними пробельными символами отказывает с кодом 2, не обращаясь к серверу лицензий. На машине, где запускается review, в том числе на раннере CI, нужна действующая лицензия Профессиональной версии, порядок активации описан в разделе Активация платной версии: без неё сравнение не выполняется и команда завершается с кодом 2. Флаги и число файлов проверяются раньше лицензии, поэтому --help и без лицензии даёт 0, а ошибка во флаге перед файлами даёт 1. Ключ рассчитан на одну машину: активация на раннере переносит ключ туда, и если с тем же ключом работает сервер разработчика, он может остаться без платных инструментов или забрать ключ обратно. Частые активации сервер лицензий может отклонить; что делать при отказе, описано в разделе Если активация не прошла.

Какие флаги у команды review?

Основные флаги команды review:

--format markdown|json|text   формат отчёта (по умолчанию markdown)
--ignore-*                    11 флагов фильтрации технического шума
                              (trailing whitespace, line endings, BOM, порядок UUID и т.д.)
--no-watermark                убрать подпись оплаченной лицензии (подпись Trial остаётся)
--diagnostic                  zip с диагностикой для тикетов
--bug-report                  PII-safe tar.gz для GitHub-issue
--enable-ibcmd                рекомендательная сверка через ibcmd (8.3.27+)

Как устроен отчёт CFEDiff?

Markdown-отчёт устроен так:

1. Заголовок с парой Base/Head и SHA-256 каждого .cfe.
2. Раздел Сводка: сколько объектов добавлено, удалено, изменено, и счётчик строк BSL со знаком плюс и минус.
3. Далее идут секции по каждому изменённому объекту с unified-diff хунками (@@).
4. Раздел Активные фильтры: какие --ignore-* были применены.

CFEDiff читает два формата выгрузки:

• Canonical Designer: выгрузка через DESIGNER /DumpCfg (8.3.x).
• ibcmd-Mac/Linux: выгрузка через ibcmd config export (8.3.27+).

Как сверить основную конфигурацию с расширением (base_vs_ext)?

Второе действие, base_vs_ext, сравнивает основную конфигурацию с расширением по их XML-дампам. Для собственных объектов расширения отчёт показывает состав на уровне свойств и подписки. Для заимствованных объектов (объектов основной конфигурации, добавленных в расширение) видны переопределённые свойства, добавленные реквизиты и табличные части, а также перехваты &Вместо и &ИзменениеИКонтроль относительно базы.

Без base или base_dump выводятся только собственные объекты расширения, сверка с базой не выполняется. Действие доступно с версии v2.17.0.

Что делает второе мнение через ibcmd?

Флаг --enable-ibcmd задуман как необязательная рекомендательная (advisory) проверка, которая не блокирует работу: независимо пересчитать результат сравнения через официальную утилиту 1С ibcmd и сопоставить с основным. Вызывается из командной строки, флаг ставится перед файлами:

mcp-1c-pro review --enable-ibcmd base.cfe head.cfe

Сверка идёт, только если на машине есть ibcmd: утилита выгружает обе версии расширения, и сверка сравнивает, какие объекты изменились по этой выгрузке и по основному diff, среди объектов тех видов, которые основной diff назвал по имени. С версии 2.41.0 переименованный объект входит в сравнение под старым и новым именем. Если наборы совпали, предупреждения нет, если разошлись, приходит предупреждение IBCMD_VALIDATION_FAILED. С той же версии расхождением считается и прогон, где основной diff не назвал по имени ни одного изменённого объекта, а ibcmd изменённые объекты назвал. Если утилиты нет или выгрузка не удалась, сверка пропускается с предупреждением IBCMD_NOT_AVAILABLE. Результат основного diff от неё не зависит и не блокируется, код возврата не меняется. Опция появилась в v2.19.0 и доступна только в командной строке.

Какие есть ограничения?

CFEDiff честен про свои границы:

• Структурно форма сравнивается, только если её поток лежит в контейнере под ключом form/Form.0: тогда видны реквизиты, элементы с их свойствами и обработчики. В проверенных контейнерах таких потоков нет: форма лежит в записи объекта вместе с модулем формы и сравнивается по байтам, и отчёт говорит только, что байты различаются.
• Из метаданных объекта читаются только имя и вид. Изменение синонима, свойств или состава видно лишь как отличие байтов; с версии 2.41.0 это отличие названо и у объекта, для которого показан дифф модуля. Реквизиты и табличные части по имени не сравниваются.
• Объект, имя которого не читается из заголовка его метаданных, показан под UUID. С версии 2.41.0 объект с тем же UUID и другим именем, если имя прочитано на обеих сторонах, показан одной записью с обоими именами и пометкой «(переименован)».

В каких редакциях работает review и есть ли пробный период?

Поведение review зависит от лицензии:

Для Профессиональной редакции есть 14-дневный пробный период со всеми функциями тарифа без ограничений. Цены и состав редакций на странице тарифов.

Как запустить?

Для самого сравнения .cfe подключение к работающей базе не требуется: CFEDiff работает с файлами. Ниже иллюстративный пример запуска Профессиональной редакции по stdio в Claude Desktop, чтобы инструмент code_review стал доступен ассистенту.

{
  "mcpServers": {
    "mcp-1c": {
      "command": "/usr/local/bin/mcp-1c-pro",
      "args": [
        "--base", "http://localhost/acc/hs/mcp-1c",
        "--user", "Администратор",
        "--password", ""
      ]
    }
  }
}

Файл конфигурации Claude Desktop:

macOS:   ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Действие review_extension работает с путями к .cfe, а base_vs_ext с каталогами XML-дампов. Подробности по инструментам в документации, общий обзор продукта MCP-1C на главной.