1C:SRE-Suite: автоматизируем непрерывную интеграцию (CI) через GitHub Actions

В первой части нашей публикации мы рассмотрели общую архитектуру SRE-пакета для платформы «1С:Предприятие» в операционной системе Linux. Мы заложили теоретический и практический фундамент: описали пятислойный сборочный скрипт защиты от ложного успеха, утилиту автоматической трансляции проектов EDT и превентивные механизмы ротации процессов.

Однако декларативное описание инфраструктуры работает на полную мощность только тогда, когда оно встроено в автоматический цикл обратной связи. Любой коммит разработчика или аналитика должен автоматически проверяться на синтаксическую корректность до того, как изменения попадут в общую базу.

Во второй части нашего цикла мы подробно разберем построение конвейера непрерывной интеграции (CI) на базе GitHub Actions. Мы покажем внутреннюю структуру конфигурационного файла github-actions-ci.yml, разберем сетевые нюансы взаимодействия с серверами лицензирования и покажем, как изолировать параллельные сессии сборки в контейнерах. Исходный код проекта и пайплайнов открыт на GitHub: NickScherbakov/1c-sre-suite.

📂 Разбор пайплайна: шаг за шагом

Файл конфигурации github-actions-ci.yml описывает один рабочий процесс (Workflow), который автоматически активируется при отправке кода (push) или создании запросов на слияние (pull request) в ветки main и master. Это гарантирует контроль качества на самых ранних этапах жизненного цикла разработки.

Шаг 1. Получение актуальных исходников

Конвейер использует стандартный шаг actions/checkout@v4. Важнейшей деталью является параметр fetch-depth: 0. По умолчанию GitHub Actions скачивает только последний коммит, что ускоряет процесс, однако для полноценной работы упреждающего контроля и расчета разницы метаданных (diff-верификация на пятом слое нашего сборочного скрипта) критически необходима полная история изменений. Указание нулевой глубины извлечения исключает ложные срабатывания.

Шаг 2. Развертывание окружения Node.js

Для работы нашего транслятора из формата 1C:EDT в бинарный конфигурационный файл требуется выполнение скрипта scripts/edt-to-configurator.js. Пайплайн разворачивает виртуальное окружение Node.js 20 и выполняет команду детерминированной установки зависимостей npm ci, если в корне проекта присутствует файл package.json. Если манифест отсутствует, шаг безопасно пропускается, не прерывая конвейер.

Шаг 3. Динамическая сборка Docker-контейнера

Для компиляции кода 1С необходима установленная платформа. Наш конвейер не требует ручной предустановки платформы на сам GitHub-раннер. Вместо этого пайплайн собирает воспроизводимый образ сборочного агента 1c-sre-runner:latest из docker/Dockerfile. В этот образ уже упакованы все необходимые зависимости: виртуальный фреймбуфер Xvfb, системные шрифты MS Core Fonts и утилиты администрирования.

Шаг 4. Запуск тестирования внутри контейнера

Это технологически ключевой этап, где одновременно решаются три классические проблемы интеграции 1С в CI-процессы: сетевая доступность лицензий, изоляция параллельных сессий и безопасность конфиденциальной информации.

Команда запуска контейнера выглядит следующим образом:

1docker run --rm \
2  --net=host \
3  -v ${{ github.workspace }}:/workspace \
4  -w /workspace \
5  -e RUN_ID="$RUN_ID" \
6  -e HASP_SERVER_IP="$HASP_SERVER_IP" \
7  1c-sre-runner:latest \
8  bash scripts/1c-ci-linux-build-v4.sh

 1name: 1C:SRE-Suite CI
 2
 3on:
 4  push:
 5    branches: [ main, master ]
 6  pull_request:
 7    branches: [ main, master ]
 8
 9jobs:
10  syntax-check:
11    runs-on: ubuntu-latest
12    steps:
13      - name: Шаг 1. Получение актуальных исходников
14        uses: actions/checkout@v4
15        with:
16          fetch-depth: 0
17
18      - name: Шаг 2. Развертывание окружения Node.js
19        uses: actions/setup-node@v4
20        with:
21          node-version: 20
22
23      - name: Установка зависимостей EDT-моста
24        run: |
25          if [ -f package.json ]; then npm ci; fi
26
27      - name: Шаг 3. Сборка сборочного Docker-образа
28        run: |
29          docker build -t 1c-sre-runner:latest ./docker
30
31      - name: Шаг 4. Запуск тестирования внутри контейнера
32        env:
33          RUN_ID: ${{ github.run_id }}
34          HASP_SERVER_IP: ${{ secrets.HASP_SERVER_IP }}
35        run: |
36          docker run --rm \
37            --net=host \
38            -v ${{ github.workspace }}:/workspace \
39            -w /workspace \
40            -e RUN_ID="$RUN_ID" \
41            -e HASP_SERVER_IP="$HASP_SERVER_IP" \
42            1c-sre-runner:latest \
43            bash scripts/1c-ci-linux-build-v4.sh

 (!!!) - Три инженерных решения в основе запуска контейнера

Разберем детально, какие критические инфраструктурные барьеры устраняет приведенная команда запуска раннера.

1. Сетевой режим host вместо моста (bridge)

По умолчанию Docker запускает контейнеры в изолированной виртуальной сети. Для работы платформы «1С:Предприятие» внутри контейнера критически важен доступ к ключам защиты. Если используются аппаратные HASP-ключи, платформа пытается обнаружить менеджер лицензий по протоколу UDP. В режиме виртуального моста (bridge) широковещательные UDP-запросы не проходят сквозь сетевой экран Docker.

Параметр --net=host заставляет контейнер использовать сетевой стек хост-системы. Это полностью снимает сетевые ограничения: контейнер видит локальную сеть точно так же, как сам GitHub-раннер, что гарантирует мгновенное получение программных или аппаратных лицензий без сложной маршрутизации.

2. Двухсторонняя изоляция через переменные окружения

При одновременном запуске нескольких сборочных конвейеров на одном физическом сервере процессы Конфигуратора неизбежно сталкиваются с конфликтами захвата файлов блокировок (*.1cLck, 1Cv8.lk) или мешают друг другу во временных базах данных.

Для решения этой проблемы мы передаем внутрь контейнера переменную RUN_ID, значением которой выступает уникальный идентификатор текущего запуска GitHub Actions (${{ github.run_id }}). Наш сборочный скрипт использует этот идентификатор для создания изолированных каталогов временных файлов и выделенных баз данных, гарантируя полное отсутствие коллизий при параллельной работе.

3. Безопасность инфраструктурных параметров через GitHub Secrets

Адрес сервера лицензирования или параметры подключения к базам данных ни при каких условиях не должны храниться в публичном репозитории в открытом виде. Это создает прямую угрозу компрометации защищенного контура предприятия.

Мы используем механизм шифрованных секретов GitHub Secrets. Переменная HASP_SERVER_IP наполняется динамически из секрета ${{ secrets.HASP_SERVER_IP }}. Значение автоматически маскируется в логах сборки и передается исключительно в переменные окружения контейнера на время выполнения шага. Наш сборочный скрипт считывает эту переменную и на лету подставляет её в файл конфигурации nethasp.ini, обеспечивая строгую точечную адресацию без сетевых таймаутов.

🤝 Подключайтесь к развитию проекта

Наш конфигурационный файл GitHub Actions представляет собой готовое промышленное решение, которое легко масштабировать под любые другие платформы автоматизации: GitLab CI, TeamCity или Jenkins.

Мы продолжаем активную разработку 1C:SRE-Suite на GitHub и приглашаем инженеров принять участие в формировании открытых отраслевых стандартов эксплуатации 1С.

Готовый файл github-actions-ci.yml доступен в репозитории проекта и готов к внедрению в ваши рабочие контуры. Ждем ваши отзывы, архитектурные идеи в разделе Issue и пул-реквесты в репозитории NickScherbakov/1c-sre-suite!