Расширение интеграции GitLab 1.0.4.31
Исправление ошибок:
BF/00-00000152:При загрузке ошибок из общей ветки тестирования возникает ошибка и ошибка не загружается
Проблема определения версии, общая ветка тестирования имеет вид "Ветка версии", однако в отличие от ветки версии, версии с этой веткой не связана
 
Версию для общей ветки тестирования получается из родительской верки, так же как и для веток исправления ошибок и техпроектов.
Реализация функционала:
№00-00000003:Если отсутствует пользовательские логин/пароль в дереве ИБ попытаться взять их из родителя - Dev/104:Поиск пароля пользователя по дереву инф. баз. если для текущей базы данные не указаны.
Если для текущей ИБ не указаны имя пользователя и пароль, то при запуске из СППР инф. базы будет предпринята попытка найти учётные данные в родительских базах, если данные будут найдены, то они будут использованы для запуска.
Отключена блокировка начальный (тартовых диалогов) при открытии ИБ из СППР, так как для больших ИБ запуск длится долго и непонятно что то происходит или нет. Пользователи нажимали сразу по несколько раз.
 
Расширение интеграции GitLab 1.0.4.30
Исправление ошибок:
BF/00-00000142:Не выводится информация об обновлениях других подсистем, если в подсистеме GLI нет обновлений
При установке флага необходимости вывода обновлений не учитывалось предыдущее значение, и если подсистема требующая вывода по порядку выполнения обработчиков была ранее, то значение установленное ею терялось.
 
Учтено значение флага предыдущей итерации обновления.
BF/00-00000146:Сообщения от фоновых процедур приходят в активное окно.
Прина ошибки - не заполненный "Идентификатор назначения" у сообщений в списке из фонового задания, который приходит на клиента для вывода.
 
Лог сообщений фонового задания теперь выводится только в сообщения того окна, из которого была проинициализирована длительная процедура, сообщение об окончании фонового задания (успешное или нет) выводится в текущее окно.
BF/00-00000147:При сборке ветки master (Основная ветка проекта) некорректно определяется и устанавливается версия
Алгоритм поиска основывался на поиске самой последней слитой "Ветки версии" в "Основную ветку проекта", однако в версии 2.0.7.3 вставили запрет на установку статуса "Помещена" для веток версии, в результате все ветки версий встали в состояние "Разрабатывается" поэтому алгоритм стал считать. что ни одной ветки версии ещё не был ослито и брал самую первую версию, доступную для получения из веток версий.
 
Изменён алгоритм поиска текущей версии основной ветки проекта. Поиск производится по регистру сведений "коммиты слияния" двумя способами: при поиске во время события gitlab pipeline по идентификатору принятого запроса на слияние, в прочих случаях, например при открытии ветки основного проекта по максимальной версии ветки версии, слитой в основную ветку проекта.
В форме ветки улучшено отображение информации о версии.
 
Расширение интеграции GitLab 1.0.4.29
Исправление ошибок:
BF/00-00000141:В форме элемента "Ветки" отсутствует кнопка создания ветки
В импортрованной форме иденнтификатры команды пресоздания ветки тестироваия и создания ветки гит оказалить одинаковыми
 
Идентификатор новой команды GLI_ПересоздатьВеткуТестирования сделан оникальным по отношению к команде базовой формы. СоздатьВетку
Реализация функционала:
№00-00000021:Нужно добавить в проект основной СУБД и Кластер, либо признак "Основной" в кластере и СУБД - TP/00-00000015:Доработки по СУБД
В справочники "СУБД" и "Кластеры 1С" добавлен признак "Основной", который можно использовать в логике скриптов для определения текущего кластера 1С и/или СУБД как основного.
№00-00000026:Необходимо в кластер СУБД добавить реквизит порт, для поддержки кластеров СУБД на нестандартном порту - TP/00-00000015:Доработки по СУБД
В справочник СУБД добавлено поле "Порт", в справочник ТипыСУБД добавлено поле "ПортПоУмолчанию" Изменено представление кластера СУБД как "Имя[:Порт]", если поле порт в элементе не заполнено/очищено то порт в представлении не используется. Эти реквизиты предназначены для различения кластеров СУБД в скриптах и подстановки правильного порта подключения к серверу СУБД. Ранее такая возможность не предоставлялась. При обновлении на релиз 1.0.4.29 / стартовый запуск в Алгоритмы получения япеременных добавляется переменная SDB_Port, позволяющая определить наличие параметра - нестандартного порта и вернуть строку подстановки порта.
№00-00000025:Исполнение пакетных файлов на удалённом сервере используя передачу scp / ssh - TP/00-00000014:Исполнение пакетных файлов на удалённом сервере используя передачу scp / ssh
В обработке "Настройка уведомлений о сборках и подключение к GitLab API" раздел "Настройки Gitlab API" переименованы в "Настройки по проектам". В настройки добавлена возможность указывать сервер удалённого тестового контура, в котором будут исполняться сценарии работы с информационными базами, аналогично тому, как с ними работает gitlab-runner установленный на сервере тестового контура. Доступ к серверу организуется посредством ssh соединения. Само ssh соединение должно быть настроено по сертификату без использования пароля от имени учётной записи рабочих серверов, в контексте которых работает база СППР. Частный сценарий, когда СППР размещена на том же сервере что и другие базы проекта работает таким же образом, через ssh подключение рабочего процесса сервера к самому себе, возможно даже в контексте той же учётной записи, однако идеальный вариант подключения в контексте учетной записи под которой исполняется gitlab-runner - в этом случае все необходимые настройки привилегий нужно будет выполнить для одной учетной записи. Возможность исполнять сценарии на удаленном сервере включается в обработке "Настройка уведомлений о сборках и подключение к GitLab API" в разделе "Настройки командного процессора в Windows/Linux" в зависимости о тконтекста ОС, на которой развернут кластер 1С:Предприятия с ИБ СППР включением опции "Remote SSH bash" в этом случае в следующем разделе для каждого проекта можно указать пользователя и удаленный сервер, в контексте которых будут исполняться пакетные файлы, например gitlab-runner@GreatProject.
ВАЖНО выполнить настройки сертификата и установить его на удалённый сервер до включения режима, в противном случае скрипты будут зависать на подтверждении отпечатка и вводе пароля. Установка сертификата производится обычным образом:
user$sudo su usr1cv8
usr1cv8$ssh_keygen
usr1cv8$ssh-copy-id gitlab-runner@GreatProject
Проверяем соединение:
usr1cv8$ssh gitlab-runner@GreatProject
Должно произойти подключение к удалённому серверу без пароля и запросов на подтверждение отпечатка удалённого компьютера.
Для серверов кластера СППР на платформе ниже Windows 10/Windows Server 2019 необходимо устанавливать ssh клиента софт от стороннего разработчика, например https://hostadvice.com/how-to/web-hosting/windows/how-to-install-an-openssh-server-client-on-a-windows-2016-server/ Так же следует помнить, что для 32х битного сервера 1С клиент ssh не доступен на платформах где он присутствует из-за виртуализации каталога Windows 10/Windows Server 2019 для 32х битных приложений, как выход скопировать утилиты в Program files (x86) и настроить пути в PATH к ним для пользователя УЗ рабочего сервера 1С.
Таким образом. Вашему серверу СППР для доступа к тестовому контуру будет достаточно открыть всего лишь один порт - 22. В случае если тестовый контур построен на платформе Windows 10/Windows server 2019, то можно включить WSL и настроить на нем ssh сервер, рекомендуется использование именно версии WSL1, так как только в ней есть возможность запустить необходимые службы WSL в контексте всего сервера, а не в контексте пользователя, под которым инициализирована WSL2 (все службы стартуют в момент первого обращения). Включение необходимых служб производится запуском задания планировщика с видом задания "При включении компьютера" с пакетным файлом вида:
#!/bin/bash
sudoPW="MyAwesomeSuperUserPassword"
echo $sudoPW | sudo -S --prompt="" service bind9 start
echo $sudoPW | sudo -S --prompt="" service ssh start
unset sudoPW
Так же внутрь WSL придётся установить платформу 1С:Предприятия соответствующей версии и утилиты работы с MS-SQL (sqlcmd) если он используется у вас в проекте.
ВАЖНО переключение в режим командного процессора Remote SSH bash имеет эффект на все проекты, т.е. скрипты написанные на CMD должны быть переписаны под bash.
Технические подробности реализации нового механизма в сравнении:
В этом режиме командный файл формируется на стороне сервера 1C под управлением СППР с расширением "Управление сборкой" и отправляется на удалённый сервер посредством scp, далее исполняется на удалённом сервере посредством ssh полученный лог исполнения собирается в режиме реального времени и отображается при исполнении пакетного файла. При этом требуется лишь доступ по протоколу ssh (22й порт) к серверу ssh тестового контура.
Предыдущие варианты:
Пакетный файл формируется на стороне сервера 1С под управлением СППР с расширением "Управление сборкой" и исполняется на нём же в зависимости от окружения и выбранного варианта в командном процессоре bash/cmd/git-bash/WSL bash, что требует непосредственного доступа к тестовому контуру по локальной сети или посредством VPN соединения и, соответственно, требует открытия всех необходимых портов для доступа к кластеру 1С предприятия и СУБД тестового контура.
 
Расширение интеграции GitLab 1.0.4.28
Исправление ошибок:
BF/00-00000134:При записи группы технических проектов возникает ошибка
Проверка заполнения реквизитов, не существующих для группы.
 
Отключена проверка заполнения для группы
 
Расширение интеграции GitLab 1.0.4.27
Исправление ошибок:
BF/00-00000132:По окончании пакетного задания выдаётся ошибка записи отладочной информации пакетного задания
Само задание отрабатывает корректно. Разные способы передачи результатов завершения фонового задания. Для не предопределенных заданий требуется дополнительное получение результатов из временного хранилища.
 
Внесены требуемые изменения.
BF/00-00000133:Новая сборочная линия не прерывает текущую, если новая это линия запроса на слияние
Ранее, в целях оптимизации обработки запроса обработка прерывания сборочных линии проводилась, если их количество было более одной, так как сборочные линии запросов на слияние не использовались и для конфлита их должно было быть как минимум две. Однако теперь, так как новая линия идёт от запроса на слияние, то в выборку попадала только одна обычная сборочная линия, что не соответствовало условию количества.
 
Анализируются линии, попадающие под условие с количеством больше нуля.
 
Расширение интеграции GitLab 1.0.4.26
Реализация функционала:
№00-00000024:Адаптация расширения до версии базовой конфигурации СППР 2.0.7.3 - Dev/104:Обновление расширения под новую конфигурацию СППР 2.0.7.3
Расширение адаптировано под новую версию 2.0.7.3
 
Расширение интеграции GitLab 1.0.3.25
Исправление ошибок:
BF/00-00000120:При нажатии на кнопку открытия открывается толстый клиент
При указании версии клиента и каталога исполняемых файлов но при не указании типа клиента запускается процесс толстого клиента, а на 1С стартера.
 
Добавлен параметр запуска тонкого клиента. теперь, вне зависимости от того, указан или не указана версия будет запускаться тонкий клиент.
BF/00-00000121:При добавлении нового этапа в сборочной линии появляется сообщение об ошибке.
Не отработано событие при окончании редактирования, которое так же должно добавлять для добавленной строки имя условия
 
Исправлен обработчик при добавлении новой строки.
Реализация функционала:
№00-00000022:Использование MINGW64 в качестве командного процессора на Windows серверах - TP/00-00000011:Использование MINGW64 в качестве командного процессора на Windows серверах
Если ИБ СППР размещёна в кластере 1С для Windows, тогда в настройках появляется возможность выбрать два дополнительных варианта: использования командного процессора MINGW64 git-bash и WSL bash
В этом случае все обслужива.щие скрипты (не относится к скриптам сборочного конвейера) должны быть написаны на bash с учетом реализации этих командных процессоров в WIndows, например git-bash использует и запускает приложения, установленные в Windows, WSL только то, что установлено в подсистеме Windows для Linux. Таким образом скрипты написанные на одной платформе (Linux) гораздо проще будет адаптировать под СППР размещенную на платформе Windows.
 
Расширение интеграции GitLab 1.0.3.24
Исправление ошибок:
BF/00-00000120:При нажатии на кнопку открытия открывается толстый клиент
При указании версии клиента и каталога исполняемых файлов но при не указании типа клиента запускается процесс толстого клиента, а на 1С стартера.
 
Добавлен параметр запуска тонкого клиента. теперь, вне зависимости от того, указан или не указана версия будет запускаться тонкий клиент.
 
Расширение интеграции GitLab 1.0.3.23
Исправление ошибок:
BF/00-00000115:В некоторых случаях замещаются реквизиты подключения к ИБ и наследуемая ИБ при открытии
Новый алгоритм заполнения параметров ИБ при открытии элемента не учитывает его состояние, что элемент уже записан и все реквизиты заполнены.
1. При открытии ИБ, если она с родителем имеет одну ветку (не удовлетворяет по правилу начального заполнения родителя ИБ соответствует родителю ветки), поле "Наследуемая ИБ" затирается
2. При замене ветки в существующем элементе справочника ИБ затираются значения полей "Кластер,СУБД,Размещение,Пользователь,Пароль"
3. При создании ИБ на основании родительской, после выбора ветки, родитель которой не соответствует родителю ИБ поле "Наследуемая ИБ" затирается

 
Исправлены проблемы при изменении существующих и новых элементов справочника ИБ с заполненным полем Наследуемая ИБ: Если поле Наследуемая ИБ заполнено, то оно не изменяется при измении объекта сборки, а так же добавляется в список выбора для поля, возможные другие варианты в списке выбора подставляются по правилу: базы присоединённые к родительской ветке от выбранной.
 
Расширение интеграции GitLab 1.0.3.22
Исправление ошибок:
BF/00-00000077:Новая сборочная линия не прерывает текущую, если это линия запроса на слияние.
В запрос Gitlab API по ссылке не попадают сборочные линии запущенные из запроса на слияние, так как в ссылке у них не ссылка на ветку, а ссылка на запрос на слияние.
 
При проверке устаревших запущенных или ожидающих сборки линий дополнительно проверяются сборочные линии с источником (source) merge_request_event, для каждой полученной ссылки на запрос на слияние в поле ref проверяется source_branch, и если он совпадает с текущей запущенной веткой, то сборочная линия прерывается.
BF/00-00000114:При вереходе в объектах сборки по нав. ссылке отбор на текущий объект не выставляется
При установке отбора использован параметр РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Обычный, чтобы было видно отбор по объекту сборки в настройках параметров, однако в этом случае отбор не устанавливается. Вероятно ошибка БСП.
 
Параметр отбора заменен на РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный.
 
Расширение интеграции GitLab 1.0.3.21
Исправление ошибок:
BF/00-00000022:Ошибки, исправленные в ветке версии появляются повторно в след. сборке с момента подтверждения - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
Ошибка связана с тем, что при получении объектов для уведомления работает корректно, однако отметка объектов сборки производится либо по коммитам, либо по объектам, если их нет. В итоге в первом проходе выводятся все объекты, но отмечаются как попавшие в сборку только те что были собраны по коммитам, если отправить повторно событие то при отсутствии объектов сборки по коммитам в уведомлени попадут только те, что в прошлый раз не были отмечены, в итоге если в 3й раз отправить сообщение (наступит сборка) то уже ничего не попадёт в сообщение.
Для проверки нужно внести два исправоения по разным ошибкам. Одну исправить в ветке версии непосредственно, а другую в отдельной ветке, по запросу на слияние в ветку версии. После сборки ветки версии должны быть отмечены как собранные обе ошибки. Сейчас сначала та которая была в индивидуальной, а при повторной сборке, та, которая была собрана в ней непосредственно.
 
Разделено условие. Двойное оповещение устранено.
BF/00-00000076:При переименовании этапа сборочной линии очищаются индивидуальные задания этапа - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
При изменении имени этапа индивидуальные этапы переписываются к новому этапу, но не производится переприсвоение текстовых составляющих из старых этапов.
 
При изменении имени, или перемещении этапа вниз или вверх тексты индивидуальных заданий корректно переносятся
BF/00-00000096:При работе любых фоновых операций с ИБ выдается сообщение о копировании - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
При отображании длительного задания должно отображаться наименование задания, а не имя предопределенной задачи "Копирование"
 
При отображении информации о длительной операции подставляется её имя из справочника "Пакетные задания", за исключением предопределенной операции по копированию ИБ из родителя, при копировании из родителя выводится предопределнное сообщение о выполнении операции копировании из родителя.
BF/00-00000097:В новой версии не загружаются метаданные веток регламентным заданием - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
Вероятная причина - незаконченный рефакторинг модулей, в частности процедуры модуля ОбщегоНазначенияСППР.GLI_ПолучитьФайлыИзGIT
Тексты некоторы командных файлов под Linux не исполняются, если они записаны с спимволом первода строки CRLF
 
Проведён рефакторинг, метаданные загружаются из веток корректно.
BF/00-00000104:После обновления базовой конфигурации нарушены права на ветки, сборки, техпроекты и ошибки - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
У импортированных ролей отсутствовали необходимые разрешения, однако для предыдущей версии БСП 3.1.5 это не было проблемой.
 
Исправлены права доступа по импотированным ролям:
БазовыеПраваСППР
ЧтениеСборокВерсииПроекта
ДобавлениеИзменениеСборокВерсииПроекта
ДобавлениеИзменениеТехническихПроектов
ЧтениеТехническихПроектов
ДобавлениеИзменениеОшибок
ЧтениеОшибок
ЧтениеВеток
ДобавлениеИзменениеВеток
Реализация функционала:
№00-00000004:Обеспечить соответствие загружаемой базы коммиту созданной ветки (техпроект/ошибка) для разработки - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
- При успешной сборке идентификатор фиксации помещается в переменную "CommitID" для всех баз, которые собирались в этой сборочной линии. Для баз, у которых сборка отключена, но переменная фиксация сборки (CommitID) присутствует, к значению добавляется префикс "Expired_" это означет, что сборка ИБ не актуальна, однако можно ветку создать и от такого коммита, если именно эта база требуется для разработки.
- При копировании ИБ из родителя переменная "CommitID" прописывается в приёмную ИБ из родителя. При создании ветки из формы элемента справочника "Ветки", при нажатии на кнопку "Создать ветку в Git" появляется меню около кнопки создания, в котором перечисляются варианты создания ветки от фиксаций информационных баз или от указателя ветки, если он не совпадает ни с одной из найденных собранных баз.
- При копировании из родителя производится проверка ветки в Git базы приемника, проверяется соответствие SHA фиксации ветки SHA записанному в базе источнике, если ветка создана и SHA совпадают, предупреждений не выводится. Если не совпадают, то выводится сообщение, о том, что используемая база не соответствует выбранной SHA ветки и что потребуется полная сборка, если ИБ будет использоваться для разработки. Если ветка приемной базы не создана, то она будет создана от фиксации в родительской базе. Тем самым обеспечивается гарантированное соответствие конфигурации загружаемой разработчиком тестовой базы фиксации в хранилище, где последний раз собиралась родительская база.
№00-00000006:Отображение базы связанной с объектом сборки "Ветка исправления ошибки" в списке "Информационные базы" навигационной ссылки - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
Изменен отбор по объекту сборки в динамическом списке "Информационные
базы". Теперь, если объектом сборки является ветка исправления ошибки. а
не сама ошибка, то для ошибок, исправляемых в этой ветке база,
привязанная к ветке будет отображаться в гиперссылке навигационной
панели "Информационная база"
№00-00000007:Добавить возможность создавать ИБ в списке по навигационной ссылке "Информационные базы" с привязкой к объекту сборки - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
- Изменен порядок заполнения элемента справочника ИБ. Поле "Наследуемая ИБ" сделано доступным для изменения. Добавлен дополнительный сценарий заполнения поля, в зависимости от объекта ветки объекта сборки. Для объекта сборки анализируются ветки сборки и определяются исходные ветки, от которых ветки объекта сборки были созданы, в основном ожидается ветка версии. Для каждой родительской ветки определяются ИБ, которые собираются в родительской ветке, если такая база всего одна, то она автоматически используется в качестве родительской, если же таких баз несколько, тогда заполняется список выбора для поля "Наследуемая ИБ" Поле "Наследуемая ИБ" обязательно для заполнения во всех случаях, за исключением, когда объектом сборки является основная ветка проекта (мастер ветка, указанная в проекте). В этом случае предполагается что
создаётся новая эталонная база для мастер ветки. Таким образом, добавляется возможность создавать информационные базы для ошибок и технических проектов непосредственно в навигационной ссылке "Информационные базы". Для этого упразднена табличная часть "Дополнительные объекты сборки" справочника информационные базы, её роль исполняет новый регистр сведений "Объекты сборки ИБ" просмотреть сконвертированные объекты сборки можно по навигационной ссылке "Объекты сборки ИБ" в форме элемента справочника "Информационные базы". Первая запись появляется в регистре при записи элемента справочника с признаком "Основной", остальные при включении доработок в ветку версии / ветку
тестирования по мере принятия запросов на слияние в Git.
№00-00000017:Уменьшение размера файла сборочной линии за счет исключения задач копирования и тестирования на этапе формирования сборочного конвейера - TP/00-00000010:Важные задачи по оптимизации сборочной линии и обеспечению соответствия создаваемой ветки коммиту ИБ
Для каждого этапа добавлен текст условия на встроеном языке и размещен закладками с текстом постоянной части шаблона. Для вычисления необходимого условия в структуру Параметры, в поле ИБ передаётся ссылка на текущую информационную базу, имя этапа в поле Этап, и ссылка на объект сборки в поле ОбъектСборки. В поле Результат (по умолчанию = Истина) должен поместиться результат вычисления выражения: нужно ли включать для этой информационной базы задание в сборочную линию или нет. Если не нужно включать для указанной информационной базы то Ложь, в противном случае = Истина. Если для всех объектов сборки результат вычисления выражения будет = Ложь, этап будет полностью исключён из текста сборочного конвейера, включая и шаблон. Лимиты по умолчанию определены в документации https://docs.gitlab.com/ee/administration/instance_limits.html#maximum-size-and-depth-of-cicd-configuration-yaml-files, и могут быть переопределны на самостоятельно установленных серверах.
 
Расширение интеграции GitLab 1.0.3.20
Исправление ошибок:
BF/00-00000101:При загрузке данных тестирования из CI регламентным заданием возникает ошибка в ЖР
Проблема возникает, если использовать символьное представление проекта в виде user/project вместо идентификатора проекта
 
Добавлена замена разделителя / на %2F, в процессе тестирования выяснилось, что для сборочных линий, содержащих тесты загружаются прочие задания как тесты - исправлено.
 
Расширение интеграции GitLab 1.0.3.19
Исправление ошибок:
BF/00-00000099:При загрузке результатов тестирования в ЖР возникает ошибка 429
Ошибка 429 сервиса Gitlab сообщает о слишком частых запросах к сервису. При загрузке сборочные линии, не имеющие по факту тестов были исключены из процесса создания документа "Запуск тестирования", тем не менее попытка загрузить результаты предпринималась каждый раз. Необходимо восстановить возможность не загружать уже ранее загруженные линии.
 
Изменена стратегия загрузки заданий из сборочных линий. Ранее документ "Запуск тестирования" загружался только для тех сборочных линий, которые содержали задания с тестами, остальные сборочные линии игнорировались. Новое поведение - загружаются все сборочные линии, однако те сборочные линии, в которых заданий по тестированию нет просто записывают и проводят документ "Запуск тестирования". Регистр "Результаты тестирования" не заполняется, таким образом на результаты отчётов по тестированию это влияние не окажет. Типовой алгоритм содержит вохможность загружать вложенные сборочные линии, которые запускаются отдельным специальным заданием. В текущей редакции управления сборкой такие задания не используются, и пока не поддерживаются, но могут быть. Подобные задания считаются как "Прочие" чтобы выделить такие задания каждый этап задания сверяется с текущим составом этапов по проекту. Если заданий соответствующим этапам, маркированных "Тестирование" в справочнике "Сборочные линии" в конвейере не было, то записывается документ "Запуск тестирования" без загрузки результатов тестов, в противном случае все задания, которые не имеют отношения к тестированию будут рассмотрены как прочие тесты и будут показываться в отчёте по тестированию.
!ВАЖНО! Если переименование этапов конвейера сборочной линии было произведено до момента загрузки всех результатов сборочных линий, то задания с этапами, которые ранее присутствовали в справочнике "Сборочные линии" будут расценены как прочие, и загружены в результаты тестирования. Подобные пустые результаты можно удалить вручную, очистив регистр сведений "Результаты запуска тестов" и удалв лишние элементы в справочнике "Тесты".
BF/00-00000100:Подтверждённые исправления ошибок для неслитого технического проекта попадают в описание релиза.
Для ошибок, включенных в технические проверки не работает условие действующее на технический проект, она включается если имеет статус подтверждённой, для обычных ошибок этот статус действует тогда, когда она собрана уже в ветке версии. Ошибки, исправляемые в разных ветках не ссылаются на технический проект совсем.
 
Изменения в отчёте. Ранее ошибки, исправлчемые в разных ветках не маркировались и не связывались с техническим проектом, даже если были размещены в одном из них. Теперь они так же отражаются в составе техническог опроекта, если были включены, а так же не показываются, на равне с обычными ошибками, в описании обновления, если технический проект не был завершён должным образом: слит в ветку версию, завершены все задачи и технический проект публикуется
 
Расширение интеграции GitLab 1.0.3.18
Реализация функционала:
№00-00000016:Адаптация расширения до версии базовой конфигурации СППР 2.0.6.10 - Dev/103:Обновление расширения под новую конфигурацию СППР 2.0.6.10
Расширение адаптировано под новую версию базовой конфигурации 2.0.6.10 и версию платформы 8.3.21, в расширении отключен режим совместимости с ранними версиями платформы.
Упразднено создание ветки в Git из формы элемента справочника "Ветки" средствами расширения, так как подобный функционал реализован средствами базовой конфигурации.
Ветка версии более не переводится в состояние "Помещена" при слиянии её в основную ветку проекта, технические проекты, реализуемые в ветке версии включаются в описание обновления с учётом того, что ветка версии не принимает значение "Помещена". В отчёте "Подготовка описания обновления" так же добавлены условия для отсечения не публикуемых технических проектов и не публикуемых идей.
 
Расширение интеграции GitLab 1.0.2.16
Исправление ошибок:
BF/00-00000056:При загрузке ошибок из CI не заполняется информационная база, в итоге срабатывает контроль
В ошибках автотестов заполнена ветка, а не сборка. Контроль заполения базы нужен для корректного заполнения сборки, которая здесь не нужна.
 
Исправлено условие исключения из контроля заполнения ИБ. Для "Обнаружена" в сборке контрлируется заполнение сборки, для обнаружено в Ветке контролируется заполнение ветки.
Одновременный контроль заполнения и ветки и сборки более не используется.
BF/00-00000069:При создании ветки в Git в объекте сборки не заполняется ветка через СВ
При реализации альтернативного способа отправки уведомлений через почту была изменена фраза ключевого сообщения с "Заполнена ветка" на "Подготовлена ветка", если объект был заблокирован пользователем.
 
Заменен поиск ключевой фразы на вхожение "созданная в Git"
BF/00-00000071:Не получается отметить исправление появляется сообщение о несоответствии версии исправления.
Из указанной информационной базы извлекается последняя сборка, в ней ссылка на ветку, для публикуемых ошибок требуется заполнять сборку, а не ветку, в итоге ветка от сборки может оказаться либо мастер веткой, либо веткой тестирования, но ни в одной из них нет ссылки на ветку версии, что и приводит к сообщению проверки.
 
Для баз, собиравшихся в ветках master и ветке тестирования возвращается связанная ветка версии, связанная с master или веткой тестирования для корректной проверки соответствия версии исправления версии ветки обнаружения.
 
Расширение интеграции GitLab 1.0.2.15
Реализация функционала:
№00-00000015:Сделать резервный способ отправки уведомлений от бота вместо СВ - TP/00-00000008:Резервное уведомление о событиях по почте.
Реализован резервный механизм отправки сообщений от бота СППР по электронной почте, на случай не доступности системы взаимодействия, а также отсутствия регистрации ИБ в системе взаимодействия
Сообщения отправляются на адреса электронной почты, указанные в справочнике пользователи, в случае, если адрес электронной почты не заполнен - пользователь не получит уведомления.
Для отправки сообщений используется системная учетная запись СППР
В сообщениях используются навигационные ссылки, для открытия их из писем необходимо в реестр Windows прописать (скопировать строки ниже в файл с расширением reg и запустить с повышеными привилегиями, для 32х битных клиентов заменить Program files на Program files (x86)):

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\e1c]
@="URL:e1c"
"URL Protocol"="e1c"
"EditFlags"=hex:02,00,00,00
[HKEY_CLASSES_ROOT\e1c\DefaultIcon]
@="C:\\Program Files\\1cv8\\common\\1ceunt.dll,17"
[HKEY_CLASSES_ROOT\e1c\shell]
[HKEY_CLASSES_ROOT\e1c\shell\open]
[HKEY_CLASSES_ROOT\e1c\shell\open\command]
@="\"C:\\Program Files\\1cv8\\common\\1cestart.exe\" /URL \"%1\""
 
Расширение интеграции GitLab 1.0.2.14
Исправление ошибок:
BF/00-00000057:Некорректная отметка о сборке ошибки в составе тестовой ИБ
Объекты сборки по коммитам в ветке тестирования, время которых позже времени начала сборки, но до её окончания не должны отмечаться как собранные.
 
Добавлена обработка времени создания сборочной линии, объекты сборки включенные в ветку версии или тестирования с коммитами реквестов больше момента начала сборки исключаются из уведомеленияи отметки как собранных в ветке. Дополнительно добавлена обработка момента точного окончания сборки по данным Gitlab, ранее бралась текущая дата сервера СППР.
BF/00-00000064:При недоступности сервера взаимодействия открытие техпроектов и ошибок не доступно
При открытии происходит подключение обработчика сообщений СВ, которое заканчивается аварией при недоступности СВ
 
События подключени/отключения обработчиков сообщений помещены в блок попытка - исключение,
дополнительно обработка сообщения конвейера изменена таким образом, чтобы при невозможности разослать сообщения пользователям, остальные действия отрабатывались, даже если нет подключения (регистрации) к СВ совсем.
 
Расширение интеграции GitLab 1.0.2.13
Исправление ошибок:
BF/00-00000043:Ссылка из элемента справочника Тесты. нав ссылка Результаты тестов открывается не корректно
Указание подключения к хранилищу СППР в типовой конфигурации предусмотрено предположительно в формате ssh подключения, для форматов https и http не работает.
 
Пропатчена типовая процедура
BF/00-00000044:Не загружаются результаты тетирования в конвейерах запросов на слияние
Алгоритм не ожидает в имени ветки "refs/merge-requests/33/head"
 
Пропатчен типовой код, добавлена проверка на принадлежность сборочной линии к запросу на слияние, добавлено получние ветки источника из данных запроса на слияние
BF/00-00000045:Некоторые базы требуется исключить из тестирования
Отсутствуют пользователи, под которыми возможно тестирование, отсутствуют тестовые данные.
 
В справочник ИБ добавлен флаг "Не тестировать", флаг выведен в форму списка.
 
Расширение интеграции GitLab 1.0.2.12
Исправление ошибок:
BF/00-00000032:Не загружаются данные из контура CI, запуски тестирования создаются, но не более того
При попытке загрузить артефакты с ресурса https://gitlab.com возвращается од ошибки 302 и ссылка для скачивания в заголовках Location
 
Добавлен код обработки ошибки 302 при загрузке файла.
BF/00-00000035:В отчет "Подготовка описания версии по техпроектам и ошибкам" работает некорректно.
После рефакторинга имена секций оказались с лишними кавычками, что приводило к некорректной отработке условия фильтра
 
Исправлены значениея предопределенных параметров
 
Расширение интеграции GitLab 1.0.2.11
Реализация функционала:
ЧТЗ №:00-00000011 - Модификация загрузки результатов тестирования из CI TP/00-00000005
Добавлен флаг "Тестирование" для этапа конвейера, при загрузке результатов тестирования из CI все этапы заданий не имеющие этого флага будут пропущены.
ЧТЗ №:00-00000012 - Загрузка результатов BDD тестирования вместе с загрузкой результатов тестирования из CI TP/00-00000005
1. Добавлена возможность загружать (регистрировать ошибки) по данным автотестов в формате СППР вместе с результатами тестирования, для этого каталог с ошибками в формате СППР должен быть сохранён в артефактах сборки, таким образом при регистрации ошибки передаётся ветка, из которой эти ошибки загружались.
2. Исправлена проблема. когда пр ирегистрации ошибки не корректно в ошибке заполнялся служебный реквизит Тест, туда попадал элемент справочика случайным образом.
3. Исправлена проблема порядка загрузки сборочных линий, в типовом функционале они загружаются не последовательно, в результате, если загружается более одной за раз, и есть дублирующие ошибки, то записи в регистре формировались в неверной последовательности из за чего отчёт Результаты регистрации ошибок не работал должным образом.
 
Расширение интеграции GitLab 1.0.2.10
Исправление ошибок:
BF/00-00000025:При помещении новой ветки в Git не заполняется ветка исправления/ техпроекта
Ветка создаётся, но не заполняется, в случае если объект (Ошибка или Техпроект) заблокирован, так как не отправляется сообщение в СВ.
Сообщение не отправляестя в случае, если указан один единственный объект и ветка сборки = Пусто
 
Исправлена логика отправки сообщения, когда указан только объект
BF/00-00000026:При открытии ветки из списка ИБ ошибка
Дублирующее поле было скрыто по результатам рефакторига, однако именно с него получалась ссылка на ветку. Скрытые поля дин список оптимизировал.
 
Для реквизита ВеткаСсылка установлена обязательность, поле выведено в список и скрыта польовательская видимость
Дополнительно исправлено: для ветки вместо открытия ветки открывалось создание новой ветки.
Дополнительно: формы открытия ИБ, объектов веток, техпроектов, ошибок теперь открываются в режиме независимо.
 
Расширение интеграции GitLab 1.0.2.9
Исправление ошибок:
BF/00-00000010:При вызове алгоритма из ИБ с отработкой в фоновом режиме алгоритм не стартует с ошибкой
Ошибка рефакторинга по стандартам разработки. После переименования модуля в строке вызова осталось наименование по старому
 
Указано корректное наименование GLI_РаботаСПакетнымиФайламиВызовСервера
BF/00-00000011:При попытке создать ИБ в новом проекте возникает ошибка
В процедуру ПолучитьСписокБазСУБД передаётся список с пустой СУБД, так как у единственной ИБ поле СУБД не было заполнено.
 
Добавлена проверка на заполненость СУБД, пустые СУБД, если попали в запрос игнорируются, и по ним не производится попытки определеить доступность.
BF/00-00000012:В ошибке, при выборе информационной базы , у которой заполнено только наименование возникает ошибка.
Ошибка связана с попыткой определить связанную с ИБ ветку, а она не заполнена.
 
Добавлена проверка на заполненность объекта сборки, добавлено сообщение, что выбранная ИБ не связана с объектом сборки, поэтому номер сборки и ветка определны быть немогут, и их необходимо заполнить вручную.
BF/00-00000013:При выборе кластера в информационной базе не производится отбор в форме списка по проекту
Отсутствуют отборы по Проекту в формах
 
Добавлены отборы по владельцу в реквизиты СУБД, Кластер и Размещение
BF/00-00000014:При заполнении дополнительных параметров в ИБ возникает ошибка
Ошибка рефакторинга, изменилось имя модуля
 
Исправлена в рамказ ошибки 00-000000012
BF/00-00000016:Статус модификации ИБ после запуска алгоритмов содержащих только алгоритм подготовки переменных.
Запись элемента (формы) производилась только по окончании процесса, запущенного в фоне.
 
Добавлена запись после исполнения сценариев не в фоновом режиме.
BF/00-00000019:Отозванные и неплан. к исправ. ошибки при пересоздании тестирования вновь реквестятся в тестирование
При пересоздании ветки тестирования не анализировались статусы и состояние ошибок
 
Автоматические коммиты на слияние формируются по ошибкам в статусе "Исправлена". Остальные - пропускаются.
BF/00-00000021:При попытке сформировать описание версии возникает ошибка: Ошибка в схеме компоновки данных
В СКД задублировался параметр.
 
Удалён задублированный параметр
Реализация функционала:
ЧТЗ №:00-00000009 - Создание сценариев и обработок тестирования TP/00-00000003
1. Пропатчены методы СППР по подключению к хранилищу
2. Создана обработка эмуляции событий Gitlab API
3. Доработана обработка сборки сценариев
4. Написан тестовый конвеер сборки со скриптом тестирования.
 
Расширение интеграции GitLab 1.0.2.7
Реализация функционала:
1. Регистр настройка увдомлений администраторов расширен реквизитом
уведомлять о всех сборках
2. При выборе информационной базы заполняются автоматически номер сборки
обнаружения и ветка обнаружения
3. Сняты ограничения для веток техпроектов и ошибок по пользователям для
уведомлений, ранее пользователей можно было указать только для веток
версий и основной ветки. При формировании запроса на слияние из ветки
проверяется наличие объектов сборки и при их наличии выдаётся
уведомление о том, что лучше делать это из объектов сборки. Запрос на
слияние можно сделать из любой ветки, но в всегда в ветку источник.
4. При установке задачи процесса по техническому проекту в состояние
"Выполнена" и при установке идеи в состояние "Реализована" сбрасывается
номер сборки технического проекта.
Исправление ошибок
Исправлены выявленные ошибки