[MOD] skipSupport - добавить вариант withSupportNotModified

[GladilovDmitry]

Описание предлагаемых изменений

На данный момент есть только 2 варианта:

• withSupport - пропускаются все модули, "на поддержке"
• withSupportLocked - пропускаются только модули, находящиеся "на замке"

Получается что в случае если модуль не на замке, но не изменен - его никак нельзя пропустить.
Другими словами, нет возможности проверять только измененные модули.

Аргументация за анализ только измененных модулей

Для современных сложных конфигураций, как ERP или ERP.УХ размер кодовой базы просто огромный. Проверять все модули не рационально:

• нет смысла тратить процессорное время на анализ модуля, если он не изменялся с момента прошлой проверки; т.е. можем сократить срок ожидания результата анализа
• нет смысла анализировать модуль, если он не изменялся относительно версии поставщика - потому что например в типовом коде ERP.УХ количество ошибок и несоответствий стандартам таково, что даже их анализ (чтение человеком) - не говоря уже про исправление потребует очень много времени; при том, что зачастую из поставляемого функционала используется далеко не всё. Для того же ERP.UH первый запуск выдает 13.000 ошибок http://prntscr.com/t6bf5i

Варианты реализации:

• расcчитывать хеш модуля и сохранять рядом с .bsl
• анализировать стандартный отчет о сравнении объектов, полученный заранее из конфигуратора

[asosnoviy]

@GladilovDmitry погоди, withSupport пропустит вендорный модуль. Не пиши в нем ничего(или почти ничего) и будет оно проверять только твои.

[GladilovDmitry]

Пропустит на основании чего? Ведь в конфигурации выгруженной в файлы нет признака модифицированности модуля. Или я чего-то не знаю?

[zeegin]

модуль не на замке, но не изменен

такой ситуации ведь быть не может.

skipSupport используется для указания того что проверяемая конфигурация на поддержке и часть модулей можно не проверять.

нет смысла тратить процессорное время на анализ модуля, если он не изменялся с момента прошлой проверки; т.е. можем сократить срок ожидания результата анализа

skipSupport никак не связан с механизмами инкрементальных проверок. Кроме того инкрементальные проверки все равно должны собирать всю информацию о конфигурации, ведь для большинства проверок необходима информация о контекстах и свойствах метаданных.

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

Если модуль не изменялся - то он должен стоять на полной поддержке с замком. Если его сняли "на всякий случай" - то это организационная проблема разработки в команде. Лучше вернуть ему полный замок на место.

При использовании политики withSupportLocked подразумевается, что все, что ты разрешил редактировать, снял с замка - за то ты отвечаешь и должен устранять в этом коде ошибки, потому ошбики по такому коду ты будешь видеть. Все что ты не редактировал должно быть на полном замке и ты за это не несешь ответсвенности. Соответственно и ошибки по такому коду не видишь.

В конфигурации выгруженной в файлы есть признак модифицированности модуля. В формате выгрузки платформы его можно найти по пути Ext/ParantConfigurations.bin а для формата EDT его можно найти по пути src/Configuration/ParantConfigurations.bin.

[nixel2007]

/cc @otymko @theshadowco 🆙 последний абзац

[Stepa86]

В неизмененном модуле могут появится ошибки из-за переименования метаданных, из-за изменения апи, когда метод стал устаревшим, из-за изменения рантайма, изза подвоза новых диагностик итп.

Модуль на замке можно рассматривать как модуль, который я в этой конфе в любом случае не буду трогать, тыща там ошибок или миллиард. Трогать его будут в той базе, откуда создавалась поставка - вышестоящая ветка, поставка от вендора или разработка библиотеки другой командой. Ну или замок можно снять, принимая на себя и ошибки модуля.

@nixel2007 про ParantConfigurations.bin мы и так знаем, именно оттуда берется информация о замочках

[MinimaJack]

@nixel2007 @Stepa86 @zeegin
Может все таки ParentConfigurations.bin ?

Получается что в случае если модуль не на замке, но не изменен - его никак нельзя пропустить.

@GladilovDmitry

По идее только некоторые диагностики можно пропускать, например Typo, и то только если запуск на той же версии bls-ls

Цель какова: ускорить стат анализ?

[nixel2007]

@Stepa86 я не про замочки, а про флаг измененности модуля

[nixel2007]

@MinimaJack тут вообще все в кучу намешано...

[otymko]

/cc @otymko @theshadowco 🆙 последний абзац

Изучим вопрос. Сегодня дам обратную связь.

[zeegin]

Если вы про инкрементальную проверку то надо делать два варианта

1. изменения по гит с последней проверки
2. анализ файла дамп конфиг инфо.

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

[nixel2007]

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