Разворачивание демонстрационных баз и подключение к GitLab CI/CD.

Демонстрационная база содержит примеры как для Windows, так и для Linux и примеры в ней ориентированы на работу с СУБД MS-SQL и PostGRE SQL, чтобы соблюсти требования к кроссплатформенности. Возможно, кому-то и примеры покажутся не современными, так как в качестве командного процессора используется CMD, который начиная с 13 релиза бегунов Gitlab вроде, как и не поддерживается уже, но почему-то работает.

Вариант для Windows

Для разворачивания демонстрационной базы Вам потребуется:

1. ПК с ОС Windows (7 и выше, Server 2012R2 и выше), на котором установлено:
1. Сервер 1С:Предприятия, желательно не ниже 8.3.17.1549, возможно можно и ниже, но не могу гарантировать работоспособность. Для исключения различного рода неожиданностей, рекомендую поставить именно указанную версию платформы.
1. Установка обязательно с поддержкой публикаций на веб сервере. (компонента wsapi)
2. Блокировка ИБ для обновления запуском с ключом /C ЗавершитьРаботуПользователей требует корректно настроенного соединителя COM comcntr.dll, либо запущенного сервиса RAS. В противном случае, при запуске сборочных линий задание блокировки будет зависать на первом же этапе. Рекомендуемый вариант установки блокировок через RAS сервер. Но чтобы в дальнейшем срабатывал именно он, нужно будет эталонную базу заблокировать и разблокировать интерактивно из раздела Администрирование/Блокировка пользователей, указав этот вариант и параметры подключения к серверу RAS. Рекомендую настроить и запустить сервер RAS в любом случае, так как в механизмах администрирования информационных баз расширением «Управления сборкой» в кластере 1С:Предприятие используется именно этот способ, так как для пользователей Linux альтернатив ему нет.
2. СУБД MS-SQL от 2012 и выше. Для теста подойдут бесплатные версии.
3. Веб сервер (для публикации HTTP сервисов СППР) примеры будут на IIS, может быть и Apache, однако у него свои тонкости публикаций. У сервера Gitlab должен быть к веб серверу СППР доступ.
4. Тестовая ИБ на базе БСП. (входит в комплект поставки)
5. Дистрибутив СППР релиза 2.0.4.15.
6. EDT. В него потребуется импортировать тестовую базу на базе БСП, создать из неё проект и разместить его на сервере gitlab, требования к нему читаем ниже.
7. Рекомендую поставить, если ещё не стоит на ПК Notepad++
8. Я рекомендую для простоты все сервисы развернуть именно на одном ПК, если всё же вам немного хочется экстрима, и у вас все сервисы разнесены по разным, не забываем, что серверу 1С, на котором стоит и работает ИБ СППР нужен доступ к СУБД (1433 порт по умолчанию для MSSQL) и серверу тестового контура, где будет развёрнута тестовая ИБ на базе БСП (порты кластера должны быть доступны, по умолчанию это 1540,1541).
2. Вам потребуется учётная запись в сервисе gitlab.
1. Это может быть учётная запись в https://gitlab.com/ 
2. Или ваш локально (например, в интрасети компании) развёрнутый Gitlab CE или EE, важно чтобы он был версии не ниже 11.2. 
1. Чтобы корректно отрабатывали описанные примеры в тексте по тестам в формате jUnit, в GitLab должны быть произведены некоторые настройки. Т.е. Вам, возможно, потребуется доступ c привилегиями администратора к серверу Gitlab, чтобы включить всё это. Чтобы проверить откройте веб интерфейс Вашего сервера gitlab и добавьте в конец (выделено жирным) http://gitlab.myserver.int/help/ci/junit_test_reports.md, если не получите ошибку 404, а вместо неё получите инструкцию, значит скорее всего Вам придётся включить эту возможность, как там и описано, если нет и версия точно выше 11.2 то скорее всего всё уже включено. Вообще говоря, по-простому включение элементарно, в линуксовом terminal'е сервера с gitlab нужно набрать: 
   sudo gitlab-rails runner “Feature.enable(:junit_pipeline_view)”
2. Или, если вас тестирование и хранение результатов в формате junit не интересует, вам просто нужна возможность опубликовать ваш проект в любом сервисе gitlab.
3. Сервисы бегунов гитлаба (gitlab-runner). В демонстрационных целях мы обойдёмся одним, запуская его из командной строки. Но я рекомендую настроить 2, один установить, как службу (с повышенными привилегиями SYSTEM) и один запускать из командной строки в окне терминальной сессии и не завершать её, просто отключать. У них будет разный набор тэгов. 
4. Терпение, терпение и ещё раз терпение :)

Более подробно, по шагам. 

Приведу схему, по которой рекомендую выстраивать архитектуру тестового, продуктивного контура и контура разработки, для лучшего понимания что и где мы будем настраивать:

От этой схемы в реальной жизни были сделаны некоторые отступления, потому что эта схема была разработана для документа "Технология разветвлённой разработки, использующая git, ci/cd". Одно из отступлений отсутствие ветки release (в СППР > 2.0.2.12 для неё места не оказалось), а с учётом технологии работы ветки версии, надобность в ней просто отпала. Другое отличие, что при организации доступа сервера СППР к тестовому контуру, СППР может находиться за пределами тестового контура, и, таким образом, быть разделена между проектами. Мы так и работаем.

1. Формируем эталонные и тестовые базы в контуре тестирования
1. По правилам лицензионного соглашения, я не имею права выкладывать выгрузку (DT) демонстрационной базы, поэтому разворачиваем из дистрибутива конфигурации пустую базу СППР версии 2.0.4.15 на сервере 1С рекомендуемой версией платформы 8.3.17.1549
2. Скачиваем одним архивом: расширение GLI.CFE, выгрузку тестовой ИБ на базе БСП DemoAM.DT, обработку выгрузки и загрузки через XML, как оказалось они тоже между версиями несовместимы и данные для загрузки SPPRData.xml.
3. В развёрнутой ИБ придётся включить возможность изменения конфигурации всю или частично - на ваше усмотрение. Нужно включить иерархию элементов у справочника "Ветки" без ограничений. В расширении с учётом совместимости этого сделать невозможно. С рекомендуемой версией платформы конфигурация не запустится, поэтому сразу загружаем расширение GLI.CFE
   После применения расширения и реорганизации запускаем на выполнение. По окончании первоначального заполнения увидите историю версий расширения и основной конфигурации.
4. Добавьте пользователя с административными привилегиями, исключая имена Администратор и Иванов Иван Иванович (эти двое приедут с выгрузкой). Так же, создайте группу доступа "Открытие внешних отчетов и обработок" с одноименным профилем к внешним отчётам и обработкам, и добавьте этого пользователя туда. Поставьте стойкий пароль пользователю, если ИБ будет опубликована в интернете. Если вы будете полностью демонстрацию разворачивать у себя в интрасети (т.е. и gitlab тоже будет развернут внутри организации) и вы доверяете коллегам - можете не ставить пароли. Перезапустите ИБ СППР с новым пользователем.
5. Откройте приложенную обработку выгрузки/загрузки и загрузите демонстрационные данные SPPRData.xml:
   Загруженным пользователям Администратор и Иванов Иван Иванович дайте при необходимости стойкие пароли и добавьте их в группы Администратор и группу пользователей внешних обработок.
   Перезайдите в СППР от Иванова, или добавьте своего пользователя в группы уведомления в ветках.
6. Создаём в кластере 1С пустую ИБ, назовите DemoAM (assemble management - управление сборкой), так будет проще копировать настройки и примеры.  Загрузите в неё скачанную выгрузку тестовой ИБ на базе БСП.
7. Учётной записи пользователя кластера, где развернёте СППР требуется повысить привилегии, так как она будет запускать много всяких пакетных файлов. Для этого нужно убрать запрет для этого пользователя на локальный вход. Открываем  Win+R, в строке вводим gpedit.msc и "ОК", далее согласно картинке удаляем УЗ службы 1С из группы запрета локального входа:
   
   Если пользователя вы создавали сами, например доменного, то скорее всего это вам не потребуется , потому что 99% админов этого пользователя в указанную группу не включают.
8. Запускаем базу СППР должно появиться меню подсистемы управления сборкой:
   
9. Создаём элементы справочников СУБД, Кластер 1С, у меня это элементы с именем ПК: CHECK, где развёрнуты кластер 1С, СУБД MS-SQL, Вам нужно будет подставить свои. У меня кластер указанной версии развернут на портах выше 1940, если у Вас по умолчанию на портах выше 1540, то порт в имени кластера можно не указывать.
   
10. Далее, создаём информационную базу в одноименном справочнике, заполняя поля в последовательности как на рисунке:
    
    Конечно же порядок заполнения полей 1-7 может быть любой, главное чтобы они были корректно заполнены до нажатия на кнопку "Заполнить дополнительные переменные". Если вместо сообщений внизу как на снимке выше вы получаете другие сообщения:
    
    
    Если же всё проверили и всё равно что то не получается, то необходимо добиться, чтобы с сервера 1С, где развёрнута ИБ СППР был доступ к выбранному Вами SQL серверу из командной строки посредством SQLCMD, да поможет Вам Google или Яndex:

11. C:\Users\USER>sqlcmd -S CHECK -U sa -P *******(ваш пароль здесь) -h -1 -b -Q "SELECT name FROM master.dbo.sysdatabases WHERE name LIKE 'DemoAM'"

12. DemoAM

13. (1 rows affected)

C:\Users\USER>

14. Если всё получилось корректно то в списке ИБ напротив вашей добавленной ИБ будет зелёный кружок с галкой:
    
    !ВАЖНО! Тестовая ИБ уже готова к размещению в тестовом контуре: конфигурация стоит на полной поддержке без возможности изменения. Имитируется ситуация, когда вы создали ИБ из шаблона поставщика. Нельзя размещать базы с включённой возможностью изменения. Если по каким то причинам прежде чем начать работать с базой вам потребовалось в конфигурации включить возможность изменения, то нужно снова выключить возможность изменения и вернуть ИБ с состоянию как от поставщика, чтобы не потерять данные можно просто сохранить конфигурацию поставщика в файл, за затем загрузить эту конфигурацию игнорируя предупреждения, все сделанные изменения, естественно будут потеряны. Если в структуре базы были внесены изменения и вам их нужно сохранить, например, вы прежде чем выложить в тестовый контур исправили критичную ошибку поставщика, а обновления от него нет. В таком случае, создайте с этой базы файл поставки CF, и его загрузите в конфигурацию. Получите конфигурацию на полной поддержке, без возможности изменения но уже с вашими изменениями. На качество последующих обновлений от поставщика это сильно не повлияет, с учётом того каким образом предлагается её обновлять, однако будет считаться, что поставщик ваши изменения "удалил", поэтому лучше всё же сначала поместить типовую, свои изменения сохранить в отдельный CF, и они отдельной фиксацией пройдут в изменениях от типового. Во всех клонах базы будут иметь разную конфигурацию, относительно изначальной, в соответствии с веткой, к которой они привязаны, но все они должны быть на полной поддержке без возможности изменения. Ещё см. ниже раздел "Как обновлять базы при работе в EDT".
15. В демонстрационной базе предварительно созданы три ветки:
    
    Основную эталонную базу мы уже добавили и привязали к ветке master, создадим ещё последовательно и привяжем сначала базу версии, затем базу тестирования:
    

Конечно же в реальных проектах, где ИБ может иметь размеры более 50 Гб, копирование может отнять больше времени. Всё будет зависеть от Вашего оборудования. Поскольку хранилище проекта в gitlab ещё не создано, то полная идентичность всех трёх ИБ вполне нормальное явление, так как по сути 3 несуществующих указателя веток указывают сейчас в одно место - "в никуда".

16.               Далее, нужно проверить корректность формирования сборочной линии, прежде чем это сделать, добавим алгоритм  определения переменной в одноименном справочнике - LockVersion и алгоритм "STD". В логике сборочной линии анализируется значение этой переменной на значение SSL, и в этом случае параметры передаются немного иные, тестовая база создана на БСП версии ранее чем 3.1.5 и код завершение работы пользователей пропатчен, до функционала БСП, который есть начиная в версии 3.1.5. Если Вы вдруг захотите попробовать в качестве тестовой ИБ свою какую то базу, проверьте версию БСП, если она 3.1.5 или выше - тогда алгоритм нужно написать "SSL". После создания дополнительной переменно открываем справочник "Сборочные линии", там уже должен быть один элемент DemoAM, встаём на него и жмём кнопку "Получить текст сборочной линии". Копируем полученный текст и вставляем в Notepad++ и выбираем синтаксис YAML, далее нажимаем Alt+0, чтобы свернуть группы YAML. Должно быть примерно следующее:

Если вывод похож как на картинке, за исключением ваших имён серверов СУБД и кластера 1С то переходим к следующему этапу.

2.   Настройка системы взаимодействия и интеграции СППР с gitlab в тестовом контуре

1.   Первым делом подключаем систему взаимодействия, инструкций как это сделать есть на ИТС: Глава 6. Администрирование информационной базы :: Руководство администратора :: 1С:Предприятие 8.3.19. Документация (1c.ru). Без этого шага вы в следующий не попадёте.

2.   Следующий шаг настройка бота, получение токенов из gitlab и подключение СППР к ней.

1.   Открываем меню Управление сборкой/Сервис/Настройка уведомлений о сборках и подключение к Gitlab API
Заполняем поля, к полям простые подсказки, я поставил другой аватар для бота, чтобы отличать его от собственных тестовых баз, и жмём "Создать бота"

Обработка сама создаст пользователя СППР, отключит у него аутентификацию 1С и включит аутентификацию ОС для указанного пользователя. В результате должна форма немного изменится, вместо кнопки "Создать бота" появится кнопка "Обновить бота". В списке пользователей должен появиться новый пользователь:

Обработка так же создаст в системе взаимодействия одноименного пользователя и свяжет его с пользователем системы.

2.   В проектной деятельности, Вам лучше всего будет создать служебную учётную запись СППР в сервисе gitlab, добавить его в проект (потом вы можете этого же пользователя использовать и в других проектах). Но в демонстрационных целях мы засорять сервисы gitlab служебными пользователями не будем, я привяжу свой токен. Открываем наш сервис gitlab, у меня это будет ссылка https://gitlab.чекушкины.рф/-/profile/personal_access_tokens

Теперь пропишем скопированный токен в СППР, чуть позже придётся вернуться к этой настройке, чтобы прописать идентификатор созданного проекта:

3.   Следующим пунктом добавим себя в список администраторов сборок, чтобы получать все уведомления о сборках:

3.   Публикация HTTP сервисов СППР на веб сервере. (контур тестирования)

1.   На этом этапе я предполагаю, что вы уже заранее установили на свой ПК веб сервер, настроили его и к нему есть доступ для сервисов веб хуков gitlab. Я в своих примерах буду использовать штатный сервер https://gitlab.com, для того чтобы у него был доступ к моему СППР, мой локальный сервер IIS редиректится в домен https://чекушкины.рф, однако не все программы знают её [кириллицу], и поэтому в ссылках и коде вместо красивой кириллицы он будет выглядеть как https://xn--e1agfaq7azal4a.xn--p1ai, поэтому не пугайтесь это не ошибка, а нормальная двуличность кириллических доменов. В самом начале когда я описывал возможности функционала в части получения сборочных линий я уже сослался на опубликованную DemoAM базу СППР. Не пытайтесь открыть веб интерфейс опубликованной базы СППР, я его не публиковал из соображений безопасности, однако наша рабочая СППР опубликована в интернет, это пришлось сделать с появлением первого внештатника. 
Есть отличительная особенность, при публикации штатными средствами HTTP и веб сервисов, сделанных в расширении: при публикации ИБ на веб сервере вы не увидите ни одного HTTP сервиса из расширения, это особенность поведения конфигуратора. Поэтому, запускаем конфигуратор с повышенными привилегиями, и публикуем все http сервисы конфигурации. Если вы всё же захотите в итоге опубликовать вашу СППР в интернете, то для основной публикации базы и для http сервисов сделайте разные публикации, это связано с разными способами аутентификации. Для основной базы вы можете использовать "Проверку подлинности Windows", либо "Анонимную подлинности подлинности", для http сервисов СППР проверка может быть только анонимной, причём олицетворяющий пользователь должен быть создан отдельный в системе, например локальный пользователь сервера, где установлен сервер 1С для СППР и там же веб сервер. Поэтому открываем локальных пользователей и создаём. Не забываем про хороший пароль, в случае, если ваш веб сервер виден из интернета.

2.   Открываем конфигуратором демо базу СППР, для публикации на веб сервере. Конфигуратор нужно запускать с повышенными привилегиями (Запуск от имени администратора), Администрирование/Публикация на веб сервере
Соглашаемся на перезапуск. Если у Вас отдельный пул приложений под выбранную версию платформы (под каждую версию он должен быть отдельный, в противном случае будете получать периодически ошибку 500), то после нужно обязательно назначить его созданному приложению.

3.   Для проверки работоспособности веб сервиса получим сборочную линию,  у меня это будет ссылка: https://Чекушкины.рф/DemoAM/hs/GetPipeline/DemoAM/ci-module.yml (xn--e1agfaq7azal4a.xn--p1ai) , где DemoAM - имя публикации на веб сервере, hs/GetPipeline - имя HTTP сервиса, второй раз DemoAM - имя сборочной линии, и ci-module.yml - остаток от шаблона HTTP сервиса. В качестве ответа должны получить вывод, аналогичный при нажати и на кнопку "Получить текст сборочной линии":

4.   Создаём хранилище проекта из контура разработки.

1.   Встаём на любой из трёх ИБ в тестовом контуре (напоминаю, они пока ещё полностью идентичны), но чтобы имя сформировалось нужное, рекомендую использовать базу, привязанную к ветке версии: dev/101. Откроем и подготовим базу к загрузке в контур разработки, который у нас децентрализован, см. схему в начале раздела, выше. В процессе подготовки происходит следующее: выбранная база копируется в промежуточную базу TempDBForUpload, далее конфигурация полностью снимается с поддержки, выгружается файл ConfigDumpInfo.xml. Далее с этой ИБ создаётся архив MSSQL с суффиксом пользователя в имени в каталоге для обмена, который так же прописан в пакетном задании. К файлу ConfigDumpInfo.xml так же дописывается суффиксом имя базы.

2.   Далее пользователю необходимо загрузить два файла см. GIF выше к себе на ПК для присоединения к проекту. Т.е. в обычной ситуации, когда проект уже находится в удалённом хранилище разработчик скачивает файлы из тестового контура, восстанавливает из архива себе базу, при необходимости создаёт её себе в кластере, и заменяет файл ConfigDumpInfo.xml (далее CDI) в рабочем каталоге проекта EDT. Как это сделать останавливаться подробно не стану, это описано подробно в другой моей статье "О синхронизации ИБ с проектом в EDT". Манипуляции с файлом CDI необходимы, чтобы сэкономить время на первичной сборке, это ни много не мало, для конфигурации УХ это около 35 минут на топовом оборудовании. Если ваша конфигурация не большая, или вы ведёте разработку в расширении советами с подменой CDI можно пренебречь. 
В нашем, демонстрационном случае, хранилища ещё нет, и тестовый контур совмещён с контуром разработки, поэтому восстанавливать файлы из архива не будем, после отработки пакетного файла у нас в информационных базах MS-SQL осталась база UploadTempDB, просто переименуем её в DAM.dev.101.IvanovII (у вас может имя получиться DAM.dev.101.Administrator, если зайдёте в тестовую ИБ под пользователем Администратор). Добавляем базу с тем же именем в кластер, не создавая новой базы на СУБД, а используем уже существующую базу, и импортируем эту базу в проект EDT:

Далее делаем проект общим:

Я предлагаю создать папку git проекта DemoCMPrj внутри воркспейса EDT, у меня это будет W:\ws_DemoCM\DemoCMPrj, и проект EDT будет в подкаталоге DemoAM проекта git, именно на эту структура проекта git настроена сборочная линия. В будущем, вы конечно можете выбрать другие расположения, как Вы привыкли или как Вам удобнее. Не забываем о том, что итоговая длина пути до каталога src должна быть как можно меньше, согласно рекомендаций разработчиков EDT, в особенности если Ваша конфигурация имеет много вложенных подсистем, имеющих длинные наименования.

Далее в панели "Индексирование GitR03;R03;R03;R03;", если она не открыта то открыть её через меню "Окно/Показать панель", переносим все файлы из неиндексированных изменений в индексированные, и фиксируем изменения, в реальных проектах настоятельно рекомендую в комментарии к помещению указать версию типовой конфигурации. Например: "ERP  2.5.48.3 Типовая". Когда будете смотреть Git-blame будет сразу ясно по комментарию откуда этот код.

Далее первое  помещение нужно отправить в удалённое хранилище Git, сделаем это в панели 
"Репозитории GIT":


Вводимые каталоги потом будет поменять очень трудно, поэтому смотрим внимательно.

3.   Итогом отправки в Git имеем диалог:

5.   Теперь откроем наш проект в сервисе gitlab (здесь и в шагах далее контур тестирования): у меня это будет ссылка https://gitlab.чекушкины.рф/check/DemoAMPrg/, затем перейдём на Settings/General. Нам нужен Project ID:

Вставляем этот идентификатор куда? Там, где заполняли токен доступа к проекту:

6.   Следующим шагом будет встраивание в проект и проверка работоспособности сборочной линии. 

1.   Нам нужно в корне проекта создать файл .gitlab-ci.yml, сделаем это сразу непосредственно в сервисе gitlab, однако защита по умолчанию ветки master нам не позволит этого сделать (её конечно же можно снять в Settings/Repository/Protected branches), но мы сделаем по другому: 

2.   Завершим настройки "Демо проекта" в СППР, откроем ветку версии (dev/101) и создадим ветку версии из СППР, тем самым убедимся, что всё получилось хорошо, и запросы от СППР доходят корректно до gitlab. Открываем демо проект, закладка "Разработка"

3.   Откроем ветку dev/101

4.   Проверим в веб сервисе хранилища: 

Видим, что ветка создалась, но она не защищена. Настроим рекомендуемые параметры веток в удалённом хранилище, открываем в веб сервисе gitlab раздел Settings/Repository/Protected branches. Заменим (усилим) настройки для master (я обманул, можно было настройки конвейера запушить сразу) чтобы никто не смог ничего в ветку master запушить, и таким образом останется только один допустимый способ изменений в ветке master: запрос на слияние и его удовлетворение. Так же добавим более мягкие настройки для ветки dev/101

5.   Далее, откроем ветку dev/101: и добавим новый файл в корень проекта:

Сборочная линия готова, автоматически она не стартовала только лишь потому, что для ветки dev/101 настроена на запуск только по двум событиям: web и sheduller. Кроме того, первое задание бы застряло, так как отсутствуют бегуны, которые могли бы эти задания выполнить. Кроме этого, так как в ветке master пока ещё сборочная отсутствует, gitlab будет предлагать различные варианты готовых шаблонов в разделе CI/CD - Pipelines. Чтобы он увидел что сборочная линия уже есть, нужно слить ветку deve/101 в ветку master. Для этого необходимо создать запрос на слияние ветки dev/101 в ветку master. Сделаем это в разделе "Merge requests"

Gitlab помнит, что мы сделали фиксацию в ветке dev/101 и предлагает создать запрос на слияние в ветку master.  Если кнопки нет, то возможно с момента фиксации сборочной линии прошло более одного часа, чуть ниже и правее есть обычная кнопка создания запроса на слияние, отличие в том, что нужно будет выбрать ветку источник и ветку приёмник вручную. Далее, последовательно, записываем и принимаем запрос на слияние:

6.   Для настройки бегунов гитлаба скачиваем его по ссылке 64 бита или 32 бита. Можете, прочитать инструкцию по установке полностью.  Я рекомендую, в целях демонстрации поступить проще, запустить только одного бегуна и не устанавливать его в качестве службы.

1.   Скачиваем нужную по разрядности версию в новую папку, я создал для примера папку "D:\CI-DemoAM и загрузил 64 битную версию (файл: gitlab-runner-windows-amd64.exe) в него. Рекомендую переименовать его покороче, например grw.exe, чтобы меньше набирать в консоли.

2.   Открываем CMD, переходим в созданный каталог и запускаем бегуна с параметром регистрации:

3.  grw.exe register

4.   

5.  Runtime platform                                    arch=amd64 os=windows pid=28352 revision=f761588f version=14.10.1

6.  Enter the GitLab instance URL (for example, https://gitlab.com/):

_

7. Теперь открываем наш проект в gitlab и перейдём в раздел Settings-CI/CD-Runners
   

8.  D:\CI-DemoAM>grw register<Enter>

9.  Runtime platform                                    arch=amd64 os=windows pid=28352 revision=f761588f version=14.10.1

10. Enter the GitLab instance URL (for example, https://gitlab.com/):

11. https://gitlab.com/<Enter>

12. Enter the registration token:

13. GR********-*****************z<Enter>

14. Enter a description for the runner:

15. [CHECK]: DemoAM-runner<Enter>

16. Enter tags for the runner (comma-separated):

17. build, convertation, update, gui-command, codequality<Enter>

18. Enter optional maintenance note for the runner:

19. <Enter>

20. Registering runner... succeeded                     runner=GR13489413-fr7cX6

21. Enter an executor: ssh, custom, docker-windows, docker-ssh, parallels, shell, virtualbox, docker+machine, docker-ssh+machine, docker, kubernetes:

22. shell

23. Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

24. rem Правим файл config.toml и потом запускаем:

25. D:\CI-DemoAM>grw run<Enter>

26. Runtime platform                                    arch=amd64 os=windows pid=37232 revision=f761588f version=14.10.1

27. Starting multi-runner from D:\CI-DemoAM\config.toml...  builds=0

28. Configuration loaded                                builds=0

29. listen_address not defined, metrics & debug endpoints disabled  builds=0

[session_server].listen_address not defined, session endpoints disabled  builds=0

В процессе регистрации бегун в этом же каталоге создаст конфигурационный файл, в нём нужно исправить параметры, которые выделены
 
После запуска бегуна в gitlab его должен увидеть (обновите страницу):

30.               Далее, необходимо установить несколько переменных окружения в разделе Settings-CI/CD-Variables, они есть в тексте сборочной линии в этапе StagesAndVariables:

31. # Переменные ниже должны быть определены на сервере сборки

32. #W_PLATFORM_1C:    'C:\Program Files\1cv8\8.3.17.1549\bin\1cv8.exe'  # Путь к запускаемому толстому клиенту Windows

33. #W_PLATFORM_1C_tc: 'C:\Program Files\1cv8\8.3.17.1549\bin\1cv8c.exe' # Путь к запускаемому тонкому клиенту Windows

34. # Переменные ниже могут быть определены на сервере сборки

35. #CI_DEBUG_TRACE: "true" 

Я определю только те, которые нужны сейчас - пути к платформе, вы можете ещё и отладку включить:

36.               Осталось последнее, настроить веб хуки gitlab, для этого перейдём в раздел Settings-Webhooks, и вставим ссылку на второй HTTP сервис СППР https://xn--e1agfaq7azal4a.xn--p1ai/DemoAM/hs/BS/file.json , где подчёркнутую ссылку Вам нужно заменить на свой веб сервер: 

37.               Добавьте пользователя, под которым заходите в СППР в раздел уведомлений для ветки master (иначе не подучите уведомлений от бота о сборке):

38.               Далее, переходим в gitlab, раздел CI/CD-Pipelines и запускаем сборочную линию, на видео процесс будет немного быстрее. чем у вас первый раз, так как первый раз заполняется кэш хранилища бегуна, кэш метаданных для утилиты ring в каталоге сборки. На видео собирается параллельно 3 ветки, но вам рекомендую начат сборку с какой ни будь одной.

7.   Сейчас у ИБ для ветки версии и ветки тестирования не включён флаг копирования ИБ перед сборкой из родителя, в этом случае, прежде чем ваша база будет обновлена, допустим это ветка тестирования, из ветки версии будет скопирована ИБ с самыми свежими "тестовыми примерами" (ошибками), а затем этот клон будет обновлён до конфигурации ветки тестирования, тогда в сборочную линию добавится ещё один этап, копирование:

8.   Разница в длительности сборки не большая - 30 секунд, на больших ИБ может достигать десятки минут, 50 Гб - ~6 минут. Такой подход позволяет, быстро получить с продуктивного контура копию ИБ, накатив на неё ветку версии с выполненными задачами и проверить работоспособность функционала на свежих данных. Ещё одна выгода - в продуктивном контуре отладка как правило отключена, а ветка версии всегда в тестовом контуре, где отладка включена. Идеальный вариант делать такие сборки до начала рабочего дня (по расписанию). То же самое с веткой тестирования, её как правило собирают два раза в сутки, один раз в ночь, второй раз в обед (так же по расписанию). Ну и всегда можно запустить сборку по требованию - из веб интерфейса.

7.   На этом настройка демонстрационного контура базы закончена.