Ошибка jenkins при запуске 1с
Разработчик помещает свои изменения доработки в хранилище. Через некоторое время получает уведомление о завершении проверок. Заходит в SonarQube и видит список замечаний по своему коду.
В это время внутри:
- ГитКонвертор получает все новые изменения и коммитит их в репозиторий.
- Вручную, по расписанию или по событию стартует конвейер. Первым шагом он получает и актуализирует дженкинсфайл.
- Инициализирует все нужные переменные, заполняет пустые параметры значениями по умолчанию и готовит каталоги. Выполняет оповещение о старте конвейера.
- Получает репозиторий с кодом в подкаталог “repo”.
- Выполняется выгрузка ошибок из АПК, EDT и BSL-LS в джсон-файлы.
- Джсон-файлы обрабатываются оскриптом - вырезаются файлы на поддержке, переопределяются данные ошибок.
- Если указана папка с файлами замеров, то они конвертируются в файл покрытия.
- По исходникам получается текущая версия конфигурации. Переопределяется джава. Собираются параметры для работы СонарСканера и запускается.
- После отработки сканера конвейер ставится на паузу и ждет ответа от сервера сонара. По ответу можно сломать сборку, если порог не пройден или просто сообщить статус проверки оповещением.
Установить ГитКонвертор
Он нужен для конвертации хранилища в гит-репозиторий. Когда SonarQube работает по гит-репозиторию - появляется информация о разработчике, который внес ошибку.
ГитКонвертор можно установить на тот же сервер, где будут располагаться и другие инструменты. Плюсы от совместного размещения - экономия на количестве серверов, все в одном месте, переиспользование инструментов. Из минусов - возможные конфликты за ресурсы, уменьшение надежности.
Установить SonarQube и плагины
Сканер ставить не надо. Будет использоваться плагин дженкинса.
Комьюнити плагин для сонара доступен теперь и в маркете сонара.
Установить 1С:EDT
Если ГитКонвертор установлен на этом же сервере, то едт уже был установлен ранее. Второй раз можно не ставить.
Установить Дженкинс
Про установку хорошо написано в статье Переводим рутину ручного тестирования 1C на рельсы Jenkins-а и ADD . Именно из-за этой статьи я решил сделать единый дженкинсфайл для проверки качества кода. И в ней же узнал как это сделать.
Слейв ноду нужно обязательно настроить. АПК отказывается корректно работать, если дженкинс запущен как сервис.
Установить и настроить SonarScanner для дженкинса
Нужно не забыть про настройку вебхуков. В официальной документации про это есть, но мне помогла вот эта статья .
В конфигурации системы:
В конфигурации глобальных инструментов:
Имя сервера “ Sonar ” и имя сканера “ SonarQube Scanner ” используются в дженкинсфайле, поэтому их лучше не менять. Или поменять и в дженкинсфайле.
Создать каталог инструментов
На сервере создать папку “ C:/Sonar/ ”. Не обязательно именно этот путь, но далее буду оперировать именно им.
Положить по адресу " C:/Sonar/bin/bsl-language-server.jar ".
Установить oscript и библиотеки
choco install onescript-cli
Все приложения доступны на гитхабе.
Установить нужно в каталог “ C:/Sonar/ACC ” и создать пользователя “ Admin ” без пароля.
Создать репозиторий для дженкинсфайла
Настроить оповещения
В моем дженкинсфайле используется плагин “ RocketChat Notifier ” для отправки оповещений в рокет.чат. Если вы не используете в работе рокет.чат, то нужно самостоятельно найти и скачать подходящий вам плагин и заменить в дженкинсфайле строки “ rocketSend ” на вызов своего плагина.
Добавление проекта к проверке
Настроить ГитКонвертор
Настроить и запустить конвертацию хранилища по инструкции от ГитКонвертора.
Для работы скрипта по вырезанию файлов на поддержке нужна информация о поддержке. Поэтому в настройках нужно снять флаг “ Удалять конфигурации поставщиков ”.
После снятия флага начнет выгружаться информация о поддержке и cf-файлы конфигураций, cf-файлы нужно добавить в “ .gitignore ”.
Значения в зеленых полях потребуются в дальнейшем.
Обязательно каталог выгрузки в репозиторий должен быть на латинице. Если там кириллица - Дженкинс очень непредсказуемо себя ведет.
Настроить АПК
Запуск проверки АПК ищет конфигурацию по наименованию и использует ее.
Создать новую конфигурацию.
В наименование указать “ Каталог выгрузки в репозитории ” из ГитКонвертора.
В “ Путь к источнику проверки ” указать “ Адрес хранилища ”. Заполнить пользователя и его пароль для доступа к хранилища.
Важно, чтобы пользователи хранилища для ГитКонвертора и АПК были разными. Их никто не должен больше использовать. Иначе это приведет к конфликтам получения изменений из хранилища.
Дальше нужно настроить список проверяемых требований (выбрать все, например) и исключений, проверить подключение к базе после записи и закрыть АПК.
Стоит запустить полную проверку вручную из АПК, чтобы убедится в работоспособности.
Создание первого конвейера
Слева сверху “ Создать Item ”.
Имя Item'а - произвольное. Лишь бы было понятно что это. Лучше латиницей и без пробелов.
Тыкнуть на Pipline и нажать Ок внизу.
Откроется конфигурация джоба.
Перейти к разделу Pipline .
В Definition выбрать Pipline script from SCM .
В Credentials добавить/выбрать параметры доступа к этому репозиторию.
Стоит сразу создать Credentials для доступа к репозиторию с исходниками конфигурации и скопировать его ID . Он понадобится чуть позднее.
В Script Path - путь к дженкинсфайлу в репозитории. В моем случае это “Sonar/Jenkinsfile”.
Сохранить. И в окне джоба слева нажать на “Собрать сейчас”.
Если все настроено верно, то отработает первый шаг - получение дженкинсфайла, а потом сразу все упадет.
Указать параметры запуска конвейера
Обновить страницу джоба. Слева сверху кнопка “Собрать сейчас” превратится в “Собрать с параметрами”. Нажать на нее. Откроется окно ввода параметров.
PROJECT_NAME - ключ проекта. Именно под этим именем будет создан проект в сонаре. Именно по нему выполняется поиск конфигурации в АПК. Сюда вписываем наименование конфигурации АПК. Она же - “ Каталог выгрузки в репозитории ”.
git_repo_url - адрес репозитория git из ГитКонвертора.
git_repo_branch - имя ветки в репозитории.
sonar_catalog - каталог инструментов C:/Sonar/
PROPERTIES_CATALOG - каталог в проекте с переопределенными настройками.
ACC_check - Запуск проверки АПК перед выгрузкой ошибок.
ACC_recreateProject - Пересоздание конфигурации в АПК. Сбрасывает кэш проверки. АПК работает дольше, но все данные переполучаются заново. Актуально, когда ошибка исправлена, а АПК этого исправления “не увидела” из-за кэша.
STEBI_SETTINGS - путь к джсон файлу с переопределением ошибок. Может быть как общим из репозитория с дженкинсфайлом, так и частным для проекта.
jenkinsAgent - имя ноды на которой нужно запускать проверку. Критично к регистру.
EDT_VERSION - версия едт, которую нужно использовать.
perf_catalog - каталог с файлами замера производительности .pff. По ним создается файл с данными покрытия.
git_credentials_Id - ID Credentials для доступа к репозиторию .
rocket_channel - имя канала для отправки оповещений.
После указания всех параметров - Собрать.
Если упало на каком-то шаге. По логам определить и устранить проблему и еще раз нажать на “Собрать с параметрами”.
Если проверка АПК отработала и в конфигурации больше ничего не менялось, то для отладки и ускорения процесса можно перезапускать конвейер со снятой галкой ACC_check.
Из джобы можно перейти в проект сонара и посмотреть, что ошибки загружены.
Создание второго конвейера
Аналогично созданию конвейера нужно нажать на Создать Item , ввести имя, тыкнуть в Pipeline и внизу ввести имя существующего для копирования из него настроек.
В открывшемся окне джобы нужно поменять параметры на требуемые и запустить.
Расчет покрытия тестами
Адекватного способа рассчитать покрытие тестами в 1С на данный момент нет. Я костылю так:
Разворачиваю тестовую базу загрузкой из хранилища.
Захожу в конфигуратор. Из него запускаю менеджер тестирования под отладкой.
В менеджере тестирования подключаю тест-клиента под отладкой.
В конфигураторе включаю замеры.
Запускаю выполнение тестов.
Когда все тесты завершились, сохраняю все замеры в спец. папку, предварительно ее очистив. Эту спец. папку указываю в параметрах конвейера.
Все приложения из архива доступны на гитхабе.
Специальные предложения
(7) Да просто ни в одной компании я не видел даже просто аудита и контроля кода. Не то что автоматизации этого процесса. Ну то есть на практике не видел, на бумаге-то много чего было. Не окупается, и не работает толком, выглядит красиво и вкусно, а практического выхлопа ноль. А я много чего видел. В основном - жутковатого.
А что мучаетесь, так это очевидно, потому как нет технологии организации коллективной разработки, позволяющей эффективно, без тормозов и помех для процесса, это хотя бы мониторить. Продукт - полдела, нужна работающая концепция его применения и железобетонная воля руководства это применять, несмотря на порождаемые задержки и проблемы.
Вы на личности-то не переходите. Что есть говнокод - вопрос интересный, и не след полагать говнокодом всё, что не прошло некую верификацию. Насчёт 1С всё элементарно - я это знаю из первых рук, по крайней мере по состоянию на 2016 год. Да гляньте их поделки, сами поймёте)))
А что, качество запросов ваша система тоже проверяет? По заветам Рупасова?)
maksa2005; d4rkmesa; Andreeei; Hans; Hatson; so-quest; Светлый ум; Yakud3a; Soloist; support; + 10 – Ответить(9) Вам очень не повезло с работодателями.
Это используют. Не всегда в таком виде, иногда какие-то компоненты заменяют на другие.
После того, как втягиваешься - не понимаешь как это можно не использовать :)
Попробуйте потратить пару недель своего времени и разобраться. Сложно только по началу и от незнания процессов и инструментов.
Что касается "иногда какие-то компоненты" - через год попыток использования таких систем в 95% случаев всё сползает в прежний бардак, только "бухгалтерии прибавляется", как в том анекдоте. А дальше отдельно ритуальные телодвижения и отдельно грустная реальность. Попробуйте потратить пару недель своего времени и разобраться.
1) На счет работодателей. Возможно есть такие работодатели, которые хотя бы просто готовы применять такие инструменты, даже если на данный момент не применяют. Но их ничтожно мало и такой работодатель скорее всего будет на столько неудобно расположен от моего дома, что я к нему ни за что не поеду - такова "се ля ви")). Рынок труда таков, что обычная компания месяцами будет искать "правильных" и "неговнокодеров", а задачи нужно решать уже сегодня, а лучше вчера.
2) Попробуйте потратить пару недель. Для этого требуется сила воли, самодисциплина и мощная внутренняя мотивация; часто для этого нужно на 2 недели изменить свой образ жизни - на это вообще способны единицы из тысячи! Это практически то же самое, что сказать какому-нибудь чуваку: "попробуй бросить курить, пить пиво и займись спортом" - да ему и так хорошо! Если Вы так можете, то я пожимаю вам руку, коллега!
3) Видел один раз смешную ситуацию в одной компании: люди делали код-ревью и проверяли (автоматизированно) его на соответствие промышленным стандартам 1С. Всё бы ничего, но код был с огромным количеством технологических ошибок и огромным технологическим долгом. Ни о какой производительности, масштабируемости и гибкости такого кода речи не шло - не все знали, что у вирт. таблиц есть параметры, а уж про упр. блокировки и разницу между [ Запрос.Выполнить.Выгрузить() и Результат.Выбрать() ]и говорить не стоит - зато переменные правильно назывались!
Читайте также: