Отражаем хранилище в репозиторий git, Jenkins'ом. Опять 25

01.06.26

Разработка - DevOps и автоматизация разработки

Одна линия сборки для обработки нескольких конфигураций - выгрузка хранилищ в git, запуск анализа SonarQube.
Достаточно давно опубликовал статью на эту тему - Отражаем хранилище в репозиторий git, Jenkins'ом. Пришлось вернуться к этой теме - переосмыслить и переделать.

По мотивам статьи было реализовано ~10 линий сборки. Ну работали себе. Время от времени ломались из-за новых авторов в хранилище, чинились, работали дальше.

Но вот понадобилось добавить еще ~15 линий (отсюда "Опять 25":) и немного переделать текущие.
Начал заниматься всем этим. Но на 8-й линии уже психанул - ведь работа несложная, но кропотливая и однотипная (!). Поэтому озадачился и решил написать единую линию сборки, где все проекты были бы описаны в отдельном файле и хранились в репозитории - чтобы вообще в Jenkins не лазить. За пару вечеров допилил.

 

Предназначение

Пайплайн выгружает несколько хранилищ в git-репозитории и (опционально) запускает анализ кода sonar scanner'ом.

 
 Код пайплайна (jenkinsfile)

Ключевые возможности

  • Чтение общих и проектных настроек из JSON-файлов.
  • Фильтрация запускаемых проектов через параметр PROJECT_FILTER.
  • Группировка проектов для параллельной обработки. 
  • Опциональный таймаут для каждого проекта.
  • Безопасная работа с секретами (токен SonarQube, учетные данные Git).
  • Обработка ошибок: сбой одного проекта не останавливает весь пайплайн.
  • Использование библиотеки gitsync для переноса коммитов хранилища в Git-репозиторий.
  • Возможность задавать произвольные параметры для gitsync и sonar scanner через переменные окружения.

Большую роль играет то, что и gitsync, и sonar scanner могут параметризоваться переменными окружения. И поэтому любые такие настройки можно задать при описании общих и/или проектных настроек - эти настройки "транслируются" в переменные окружения.

 
 Пример общих настроек, с комментариями (common.json)

 

{
  # Метка Jenkins-агента, где будет происходить сборка
  "agentLabel": "sonar",
  # Настройки проектов "по умолчанию". 
  # Все ключи из default могут быть переопределены непосредственно в объекте проекта (на верхнем уровне).
  "props": {
    # Проект активен
    "active": true,
    # Кодовая страница для логов gitsync и sonar scanner 
    "codepage": "65001",
    # ID секрета, хранящего раздельно пользователя и пароль для подключения к git-репозиторию
    "gitCredentialsID": "git_token",
    # ID секрета, хранящего токен для подключения к SonarQube
    "sonarqubeTokenID": "sonarqube_token",
    # Каталог репозитория, где хранятся сами исходники
    "srcDir": "src", 
    # Запускать анализ SQ
    "useSonar": true,
    # Ветка репозитория исходников. Бывает и main, и master. Указываем, как нам нужно.
    "branch": "main",
    # Идентификатор группы проектов
    "group": 0,
    # Дополнительные параметры командной строки для gitsync
    "otherGitsyncParams": "",
    # Дополнительные параметры командной строки для sonar scanner
    "otherSonarScannerParams": "",
    # Очищать рабочий каталог перед запуском gitsync.
    "clearDir": true,
    # Можем ограничить таймаутом время сборки проекта
    "timeoutMinutes": 0
  },
  # Переменные окружения "по умолчанию"
  # Здесь и переменные gitsync, и sonar scanner.
  "env": {
    "V8VERSION": "8.3.22.2283",
    "GITSYNC_STORAGE_USER": "user_gitsync",
    "GITSYNC_DOMAIN_EMAIL": "domain.ru",
    "GITSYNC_EMAIL": "domain.ru",
    "GITSYNC_REMOTE_PUSH_N_COMMITS": "2",
    "GITSYNC_LIMIT": "0",
    "GITSYNC_REMOTE_PUSH_TAGS": "true",
    "GITSYNC_REMOTE_PUSH": "true",
    "GITSYNC_SKIP_EXISTS_TAGS": "true",
    "GITSYNC_TASK_PREFIX": "#",
    "SONAR_HOST_URL": "https://sonarqube:9443",
    "SONAR_SOURCE_ENCODING": "UTF-8",
    "SONAR_INCLUSIONS": "**\\*.bsl",
    "SONAR_SCANNER_JAVA_OPTS": "-Xmx2G",
    # Чтобы побороть ромбики в логах sonar scanner
    "JAVA_TOOL_OPTIONS": "-Dfile.encoding=UTF-8"
  }
}

* JSON не предусматривает комментарии - удалить.

 
 Пример настроек проектов, с комментариями (projects.json)

 

[
    {
        "props": {        
          # Задаем другую основную ветку
          "branch": "master"
        },
        "env": {
            # Это расширение
            "GITSYNC_EXTENSION": "РасширениеВнешниеКонтрагентыДоговоры",
            # Путь к хранилищу
            "GITSYNC_STORAGE_PATH": "//STORAGES-1C/Расширения/РасширениеВнешниеКонтрагентыДоговоры/",
            # URL git-репозитория
            "GITSYNC_REPO_URL": "https://STORAGES-GIT/docflow/ebd-external_data.git",
            # Ключ проекта SonarQube
            "SONAR_PROJECT_KEY": "ebd.external_data"
        }
    },
    {
        "props": {        
          # Выводим в отдельную группу
          "group": 1
        },
        "env": {
            "GITSYNC_STORAGE_PATH": "//STORAGES-1C/TechProjects/194_БП/",
            "GITSYNC_REPO_URL": "https://STORAGES-GIT/1c/prom/main_disconnects.git",
            "SONAR_PROJECT_KEY": "Prom_bp_disconnect",
            # Имя проекта SonarQube
            "SONAR_PROJECT_NAME": "Пром (БП Отключения)",
            # Дополнительные java-опции для sonar scanner
            "SONAR_SCANNER_JAVA_OPTS": "-Xmx8G -Xms2G -Dfile.encoding=UTF-8"
      }
    }
]

* JSON не предусматривает комментарии - удалить.

 

Примечания

  • Проектные настройки дополняют и "перекрывают" значения по умолчанию.
  • Конечный запуск cli-утилит выполняется с помощью powershell, т.к. bat как-то неустойчиво ведет себя, именно при использовании в скриптовом pipeline, - может на ровном месте зависнуть. А в freestyle-проектах такой проблемы не наблюдается.
  • Ключ проекта передается не через переменную окружения, дописан через "--define". У меня почему-то из переменной окружения sonar scanner не брал ключ. И через "-Dsonar.projectKey=" тоже не брал. А через "--define" взял.
  • Сначала выполняется параллельная сборка, затем выполняются последовательные сборки.
  • Ключ sonar-проекта (env.SONAR_PROJECT_KEY) нужно задавать, даже если анализ кода отключен. Используется для заголовка шага сборки.
  • Не проработана тема с credentials для доступа к хранилищу для gitsync. Может позже доделаю.
  • Немного озадачился безопасностью для параметров, которые могут быть дописаны в командную строку (см.метод sanitizeParams), чтобы избежать injections. Но тут тема более серьезная. Может и вообще нужно убрать эти доп.параметры командной строки.

 

Дополнительные возможности

Фильтр проектов

При запуске задания в Jenkins можно задать, какие проекты обрабатывать. Для этого нужно линию сборки сделать параметризованной, ввести параметр PROJECT_FILTER с значением по умолчанию "*".

Варианты фильтра:

  • * - все проекты, с учетом их активности
  • cf - обработка основных конфигураций, с учетом активности
  • cfe - обработка расширений
  • Ключи необходимых проектов, через пробел. Настройка активности не учитывается.

Таймауты

Можно задать таймаут (в минутах) для обработки проекта. Для отключения таймаута - указать 0 (ноль).

Группы проектов

Проекты можно группировать для параллельной обработки - задать значение для props.group. Группы проектов обрабатываются последовательно, согласно их значениям группировки.
В группе может быть и только один проект - таким приемом задается "монопольная" обработка проекта, без других параллельных.

Плагины

Требуются плагины Jenkins:

  • Pipeline Utility Steps (для `readJSON`, `readFile` и др.)
  • Git Plugin (для клонирования репозиториев)

 

Итоги

Получилась достаточно универсальная линия сборки. При этом, состав и настройки проектов определяются "снаружи", конфигурационными файлами, без захода в Jenkins.

Обновления

01.06.26

Переделал настройки (общие и проектные) - ввел группировку свойств props, для упрощения пайплайн.
Переделал механизм параллельной обработки. Теперь это выполняется группами проектов (ранее использовалось parallel). 

Вступайте в нашу телеграмм-группу Инфостарт

Jenkins SonarQube gitsync

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Тестирование QA DevOps и автоматизация разработки Программист 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.27.47.

5000 руб.

04.07.2022    14299    65    5    

40

Тестирование QA DevOps и автоматизация разработки Программист Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Автотесты 1С - готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.190.11.

5368 руб.

20.01.2022    11844    48    1    

22

Тестирование QA DevOps и автоматизация разработки Программист 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Набор универсальных подсценариев для заполнения форм типовых объектов справочников и документов конфигураций ERP 2.5 и КА 2.5. Сценарии представляют собой feature-файлы для vanessa-automation с тегом @exportscenarios. Используются для разработки функциональных сценариев.

4270 руб.

26.01.2023    5275    7    2    

3

DevOps и автоматизация разработки Программист 1С:Предприятие 8 Бесплатно (free)

Технический разбор нашего конвейера разработки на 1С: песочницы, Gitea, сборка, проверки и CLI backend'ы. Основной CLI - cursor; также поддерживаются codex, claude и экспериментальный mimo.

16.06.2026    1858    Aleksandr    1    

7

DevOps и автоматизация разработки Программист Бесплатно (free)

Хватит ограничивать себя родным и уютным стеком 1С. Пора расширять кругозор и осваивать смежные стеки! Разберемся, как Docker может упростить жизнь одинэснику: от сборки и тестирования 1С до запуска инфраструктуры и автоматизации CI/CD, причем быстро, воспроизводимо и без лишнего мусора в системе.

08.05.2026    3482    sleemp    81    

35

DevOps и автоматизация разработки Мониторинг Системный администратор Программист Бесплатно (free)

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

06.04.2026    10997    vladimir-89    12    

31

DevOps и автоматизация разработки Программист Бесплатно (free)

Если вы думаете, что внедрение CDC конвейера — это геморрой, то вы правы. Но мы уже прошли через все боли: от настройки MSSQL CDC до танцев с Kafka и ClickHouse. Теперь конвейер работает и данные ключевых операций в 1С, от которых зависит бизнес, попадают в ClickHouse, где их можно анализировать и использовать для мониторинга в реальном времени. В этой статье я расскажу, как выглядит архитектура и с какими проблемами можно столкнуться

05.03.2026    1546    NesterTop1    4    

5

DevOps и автоматизация разработки EDT Программист Бесплатно (free)

Разбираемся, почему ручной деплой в 1С все еще жив и сколько времени он на самом деле занимает, несмотря на стремительное развитие CI/CD-подходов. На реальном кейсе показываем, что корень проблемы чаще кроется не в автоматизации, а в ее неэффективной настройке. Событийная модель вместо расписаний, параллельные тесты, использование кеша Gitlab для оптимизаций и правильные настройки для управления репозиториями на раннерах радикально меняют скорость delivery. Объясняем, почему переход на Docker иногда замедляет процесс, как платформенные особенности 1С влияют на пайплайны и какие стратегии позволяют устранить узкие места. Материал будет полезен тем, кто хочет понять реальную стоимость ручного деплоя и сравнить ее с возможностями правильно настроенной автоматизации.

04.03.2026    1793    konst1231    0    

6
Для отправки сообщения требуется регистрация/авторизация