Ладно. Чуть больше информации добавлю
В "Объект" в его "ТабЧасть" добавил реквизит.Тип произвольный.
В процессе редактирования формы в этот реквизит записал произвольные данные. Структуру с перечнем полей.

При записи - мне эту стркутуру хочется поместить в ХранилищеЗначения в реквизит этой же табличной части.

Что бы его поместить - мне нужно для каждой строки объекта взять структуру преобразовать в хранилище занчения и поместить в поле Табличной чести "ТекущегоОБъекта".

Как это сделать?
Я делаю циклом по строкам ОБъекта. С поиском этой же с строки в табличной части "ТекущегоОбъекта"? Я делаю неправильно?

"добавил реквизит" // Реквизит формы что ли?

Именно

Порядок строк ТЧ у "Объект" будет совпадать со строками ТЧ в ТекущемОбъекте

Т.е. через индекс коллекции обход?

Отличие только в том, что первая ТЧ будет ДФК, а вторая - уже прям ТЧ, ну и в первой не будет реквизитов, которые не сериализуются.
Как обходить разницы нет.

Спасибо.

Всем доброго дня. Вопрос насущный:
Сейчас раз в некоторое время из jenkins запускается мониторинг изменений хранилища и при наличии изменений - запускается цепочка с помещениями в гитлаб, обновлением тестовой базы из хранилища, её тестированием форм и прочее. Получается что в между тестированиями может быть помещено несколько версий в хранилище и не так явно выявлять кто накосячил :) Поэтому пришла идея разбирать хранилище на версии, получать номер версии, кто поместил и тестировать каждую версию отдельно. C технической стороны, как я понимаю, может помочь v8storage, а вот с точки зрения опыта многих людей отсюда - насколько так оправдано делать и у кого как реализовано подобное, если реализовывали? 🤔 👨🏻‍🎓

Делали запуск тестирования до помещения в хранилище разработки по команде разработчика.

Настрой гитконвертор на помещение в гит и сборку делай на пуш в гитлаб CI.

либо используйте гитсинк. он разбирает каждую версию по отдельности и сохраняет ее номер в файл VERSION. этот файл можно в дженкинсе читать и передавать параметром для загрузки конфигурации из хранилища конкретной версии (у нас так и сделано)

Получается лучше из гита всё-таки версии брать, раз 2 из 3 таким образом реализуют? Получается мониторинг хранилища ставим почаще, чтоб чаще в гит версии новые уходили пускай и по несколько штук за раз, а там уже каждую версию получаем и издеваемся как хотим?

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

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

Окей, попробую на нашей конфигурации... ERP так теститировать конечно очень накладно  😄

поделитесь скриптом? это интересно

вот тут было: https://github.com/ripreal/erp_features

А часто косячат? может все же тестировать последнюю версию, а когда упадет устраивать git bisect или аналоги.

когда как :) Хотим поэксперементировать. Может будет лучше, может хуже. Про подсказку спасибо - у вас так построено?

"так" это в смысле того, что подряд не проверяем. Но и бисект не автоматизирован. Просто по моему опыту нечто требующее поисков "а когда оно сломалось" случается очень редко. Но у нас команда 4 человека.