Добавить step для проверки внедрения БСП
ovcharenko-di opened this issue · 16 comments
идея @zeegin
https://t.me/bsl_language_server/48681
Нужно создать внешнюю обработку-прокси для проверки внедрения БСП.
Эта обработка должна будет:
- создать объект обработки проверки внедрения
- вызывать метод программного интерфейса
ПроверитьВнедрение() - обойти ТЧ списка собранных ошибок и создать файл с ошибками
- в формате, пригодном для SQ, либо отдельным артефактом
Параметры:
- путь к выгрузке конфигурации (взять из "глобальных" параметров)
- путь к обработке проверки внедрения БСП
- исправлять ошибки = Ложь
- проверяемые\исключаемые подсистемы = (Все|Список)
- формат отчета = (xlsx|genericIssue)
- путь к файлу отчета
Ну а в библиотеке должен быть такой шаг
Отличная идея. А разве сама обработка проверки внедрения БСП не умеет себя запускать при передаче каких-нибудь параметров через /C?
@nixel2007 неа, нужен запускатор.
А еще нужно чтобы обработка проверки внедрения была той же версии что и бсп в конфигурации. С точностью до номера исправительной версии. Потому хорошо бы ещё сделать выбор правильной обработки проверки внедрения из установленных на компе в шаблонах.
Потому хорошо бы ещё сделать выбор правильной обработки проверки внедрения из установленных на компе в шаблонах.
либо просто класть ее в libs в репе.
с шаблонами идея тоже интересная, но надо учесть, что это все может запускаться на временных агентах, в которых вообще никаких шаблонов нет.
Самое главное сделать так чтобы система валилась если версии не совпадают. Так не забудешь докинуть нудную версию. А там уже все зависит от того надо тебе чтоб разные версии БСП одним Пайплайном работали или нет
@zeegin @nixel2007 эх, была бы в проверке внедрения функция ВерсияОтчета() экспортной - можно было бы запускатором сравнивать и ругаться, если не совпадают
@zeegin а вот кстати хороший вопрос от @ovcharenko-di.
как понять версию обработки?
Потому я и написал про tmplts) хз, сохранять в имени файла то из какой поставки брал. Можно сделать шаг получения нужной версии загрузкой с ИТС и сохранением куда нибудь.
@ovcharenko-di Утащил мою старую хотелку для Ванесса-АДД или Ванесса-раннер )
- я также записал эту идею при нашем обсуждении в телеге.
я одного не пойму, почему эту обработку нужно делать в текущем продукте.
обработка по запуску в общем случае может быть где угодно. все равно автоматизация запуска скорее всего будет через vrunner. но здесь точно нужно будет делать доработки для поддержки этого шага.
хотя в теории это можно обработать через запуск xunit-шага по аналогии с множественными запусками для vanessa-шага через несколько vrunner*-конфигов.
Лучше сделать универсальную обработку которую можно стартануть в пакетном режиме и получить выгрузку в нужном формате, а кто как захочет так и будет ее встраивать в пайплайн.
@zeegin да, я описался, конечно же имел ввиду не xunit-запуск, а через vrunner run
Например я ни враннер ни адд не использую и не планирую. Потому что не понимаю зачем мне пакетный режим над пакетным режимом, можно скрипты сразу в гитлаб сi писать.
@zeegin в случае vrunner run не добавляется никакой дополнительной логики. а пакетный режим конфигуратора... ну, он просто отвратительный, тут можно долго спорить :)
а запуск через vrunner xunit в теории мог бы позволить переиспользовать инфраструктуру сброса результатов в junit/allure/generic-issue без доработок.