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

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

Вариант для Linux
Примечание: некоторые изображения в тексте оставлены от варианта разворачивания на ОС Windows, так как они полностью аналогичны.

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

1. ПК с ОС Linux из поддерживаемых. Я использую Ubuntu 18.04-4. ОС должна иметь GUI. На ПК должно быть установлено:
1. Сервер 1С:Предприятия, желательно не ниже 8.3.17.1549, возможно и ниже, но не могу гарантировать работоспособность. Кроме всего клиентские части платформы ниже 8.3.16 просто работают нестабильно. Для исключения различного рода неожиданностей, рекомендую поставить именно указанную версию платформы.
1. Установка обязательно с поддержкой публикаций на веб сервере. (компонента wsapi)
2. Блокировка ИБ для обновления запуском с ключом /C ЗавершитьРаботуПользователей требует запущенного сервиса RAS. В противном случае, при запуске сборочных линий задание блокировки будет зависать на первом же этапе. По умолчанию блокировка пытается установиться в варианте COM, который в Linux не поддерживается, чтобы в дальнейшем срабатывал вариант через RAS сервер, нужно будет эталонную базу заблокировать и разблокировать интерактивно из раздела Администрирование/Блокировка пользователей, указав этот вариант и параметры подключения к серверу RAS.
2. СУБД Postrgres, пропатченный с сайта 1С версии 11.16-1.1C. Как альтернативный вариант Postgres Pro 1C 11 и выше. Я использую PostgresPro. Для сервера нужно будет снять ограничения на прием запросов только с адреса localhost.
3. Веб сервер (для публикации HTTP сервисов СППР) Apache, тонкости публикаций будут описаны ниже. У сервера Gitlab должен быть к веб серверу СППР доступ.
4. Тестовая ИБ на базе БСП. (входит в комплект поставки)
5. Дистрибутив СППР релиза 2.0.4.15.
6. EDT. В него потребуется импортировать тестовую базу на базе БСП, создать из неё проект и разместить его на сервере gitlab, требования к нему читаем ниже.
7. Рекомендую поставить, если ещё не стоит на ПК Notepad++
8. В целях демонстрации, для простоты освоения, рекомендую все сервисы развернуть именно на одном ПК, если всё же вам немного хочется экстрима, и у вас все сервисы разнесены по разным, не забываем, что серверу 1С, на котором стоит и работает ИБ СППР нужен доступ к СУБД (5432 порт по умолчанию для Postgres) и серверу тестового контура, где будет развёрнута тестовая ИБ на базе БСП (порты кластера должны быть доступны, по умолчанию это 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_1.0.2.6.zip: расширение GLI.CFE, выгрузку тестовой ИБ на базе БСП DemoAM.DT, обработку выгрузки и загрузки через XML, как оказалось они тоже между версиями несовместимы и данные для загрузки SPPRData.xml.
3. В развёрнутой ИБ придётся включить возможность изменения конфигурации всю или частично - на ваше усмотрение. Нужно включить иерархию элементов у справочника "Ветки" без ограничений. В расширении с учётом совместимости этого сделать невозможно. С рекомендуемой версией платформы конфигурация не запустится, поэтому сразу загружаем расширение GLI.CFE
   После применения расширения и реорганизации запускаем на выполнение. По окончании первоначального заполнения увидите историю версий расширения и основной конфигурации.
4. Добавьте пользователя с административными привилегиями, исключая имена Администратор и Иванов Иван Иванович (эти двое приедут с выгрузкой). Так же, создайте группу доступа "Открытие внешних отчетов и обработок" с одноименным профилем к внешним отчётам и обработкам, и добавьте этого пользователя туда. Поставьте стойкий пароль пользователю, если ИБ будет опубликована в интернете. Если вы будете полностью демонстрацию разворачивать у себя в интрасети (т.е. и gitlab тоже будет развернут внутри организации) и вы доверяете коллегам - можете не ставить пароли. После перезапуска под новым пользователем система предложит вам включить обсуждения.
   
   Согласитесь. Перезапустите ИБ СППР с новым пользователем.
5. Групповой обработкой e1cib/app/Обработка.ГрупповоеИзменениеРеквизитов, произвольным алгоритмом в режиме «Обмен.ЗагрузкаДанных=Истина» установите пометку удаления и, затем, удалите окончательно элементы справочников «Пакетные задания» и «Типы СУБД». Необходимые элементы будут загружены следующим пунктом.
6. Откройте приложенную обработку выгрузки/загрузки и загрузите демонстрационные данные SPPRData.xml:
    
   Загруженным пользователям Администратор и Иванов Иван Иванович дайте при необходимости стойкие пароли и добавьте их в группы Администратор и группу пользователей внешних обработок.
   Перезайдите в СППР от Иванова, или добавьте своего пользователя в группы уведомления в ветках.
7. Создаём в кластере 1С пустую ИБ, назовите DemoAM (assemble management - управление сборкой), так будет проще копировать настройки и примеры.  Загрузите в неё скачанную выгрузку тестовой ИБ на базе БСП.
8. В части алгоритмов используется запуск клиентских приложений 1С:Предприятия из пакетных файлов, в частности создание ИБ в кластере 1С:Предприятия, которые не могут нормально запуститься под пользователем usr1cv8, создаваемого автоматически сценарием установки, в контексте которого выполняются процессы кластера 1С:Предприятия. Для решения этой проблемы придется отключить автоматический запуск кластера:
   sudo systemctl stop srv1cv83
   sudo systemctl disable
   И далее запускать его одним из двух вариантов
1. Запуском пакетного файла:
   sudo cp ~/.Xauthority /home/usr1cv8
   sudo cp ~/.xinputrc /home/usr1cv8
   sudo chown usr1cv8:grp1cv8 /home/usr1cv8/.Xauthority
   sudo chown usr1cv8:grp1cv8 /home/usr1cv8/.xinputrc
   sudo /etc/init.d/srv1cv83 start
2. Либо просто запустить кластер в контексте пользователя с GUI:
   /opt/1C/v8.3/x86_64/ragent /port 1540 /regport 1541 /range 1560:1591 /d ~/dbinfo/.1cv8 [-debug -http -debugserverport 1550]

Есть ещё один вариант выхода: заменить вызовы создания, загрузки / выгрузки ИБ на новую утилиту ibcmd.exe из состава утилит автономного сервера, однако в практике всё равно потребуется использовать 1С:Конфигуратор для создания файлов поставки. Кроме этого, утилита ibcmd.exe работает эффективно и корректно начиная с версии платформы 8.3.20

9. Запускаем базу СППР должно появиться меню подсистемы управления сборкой:
   
10. Создаём элементы справочников СУБД, Кластер 1С, у меня это элементы с именем ПК: Ubuntu-VM2, где развёрнуты кластер 1С, СУБД Postgrespro, Вам нужно будет подставить свои. У меня кластер указанной версии развернут на портах выше 1740, если у Вас по умолчанию на портах выше 1540, то порт в имени кластера можно не указывать.
     
11. Далее, создаём информационную базу в одноименном справочнике, заполняя поля в последовательности как на рисунке:
    
    Конечно же порядок заполнения полей 1-7 может быть любой, главное чтобы они были корректно заполнены до нажатия на кнопку "Заполнить дополнительные переменные". Если вместо сообщений внизу как на снимке выше вы получаете другие сообщения:
    
    
    Если же всё проверили и всё равно что то не получается, то необходимо добиться, чтобы с сервера 1С, где развёрнута ИБ СППР был доступ к выбранному Вами SQL серверу из командной
    строки посредством psql, да поможет Вам Google или Яndex:
    evgeniy@Ubuntu-VM2:~$ /opt/pgpro/1c-11/bin/psql -U postgres -h "Ubuntu-VM2" -A -t -c "select d.datname, t.spcname from pg_catalog.pg_database d left join pg_catalog.pg_tablespace t on d.dattablespace = t.oid where d.datname = 'DemoAM'"
    DemoAM|pg_default
    evgeniy@Ubuntu-VM2:~$
12. Если всё получилось корректно, то в списке ИБ напротив вашей добавленной ИБ будет зелёный кружок с галкой:
    
    !ВАЖНО! Тестовая ИБ уже готова к размещению в тестовом контуре: конфигурация стоит на полной поддержке без возможности изменения. Имитируется ситуация, когда вы создали ИБ из шаблона поставщика. Нельзя размещать базы с включённой возможностью изменения. Если по каким-то причинам, прежде чем начать работать с базой вам потребовалось в конфигурации включить возможность изменения, то нужно снова выключить возможность изменения и вернуть ИБ к состоянию как от поставщика, чтобы не потерять данные можно просто сохранить конфигурацию поставщика в файл, за затем загрузить эту конфигурацию игнорируя предупреждения, все сделанные изменения, естественно будут потеряны. Если в структуре базы были внесены изменения и вам их нужно сохранить, например, вы, прежде чем выложить в тестовый контур исправили критичную ошибку поставщика, а обновления от него нет. В таком случае, создайте с этой базы файл поставки CF, и его загрузите в конфигурацию. Получите конфигурацию на полной поддержке, без возможности изменения, но уже с вашими изменениями. На качество последующих обновлений от поставщика это сильно не повлияет, с учётом того каким образом предлагается её обновлять, однако будет считаться, что поставщик ваши изменения "удалил", поэтому лучше всё же сначала поместить типовую, свои изменения сохранить в отдельный CF, и они отдельной фиксацией пройдут в изменениях от типового. Во всех клонах базы будут иметь разную конфигурацию, относительно изначальной, в соответствии с веткой, к которой они привязаны, но все они должны быть на полной поддержке без возможности изменения. Ещё см. ниже раздел "Как обновлять базы при работе в EDT".
13. В демонстрационной базе предварительно созданы три ветки:
    
    Основную эталонную базу мы уже добавили и привязали к ветке master, создадим ещё последовательно и привяжем сначала базу версии, затем базу тестирования:
    

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

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

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

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

1.   Первым делом подключаем систему взаимодействия, если вы это не сделали сразу на шаге 1.4, инструкция как это сделать есть на ИТС: Глава 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.чекушкины.рф, для того чтобы у него был доступ к моему СППР, мой локальный сервер Apache редиректится в домен https://linux.чекушкины.рф, однако не все программы понимают кириллицу, и поэтому в ссылках кое где указанные адреса будут выглядеть как https://gitlab.xn--e1agfaq7azal4a.xn--p1ai и https://linux.xn--e1agfaq7azal4a.xn--p1ai, это не ошибка, а нормальная «двуличность» кириллических доменов.
Есть отличительная особенность, при публикации штатными средствами HTTP и веб сервисов, сделанных в расширении: при публикации ИБ на веб сервере, вы не увидите ни одного HTTP сервиса из расширения, вместо них один единый флаг «Публиковать http сервисы расширений» это особенность поведения конфигуратора. Поэтому, запускаем конфигуратор с повышенными привилегиями (sudo /opt/1C/v8.3/x86_64/1cv8), и публикуем все http сервисы конфигурации:

Если вы всё же захотите в итоге опубликовать вашу СППР в интернете, то для основной публикации базы и для http сервисов сделайте разные публикации, это связано с разными способами аутентификации. Для основной базы будет использоваться стандартная аутентификация. А для http сервисов СППР имя пользователя и пароль нужно задать прямо в публикации.
Соглашаемся на перезапуск. Откроем конфигурационный файл vim /var/www/DemoAM/default.vrd и добавим логин и пароль для пользователя веб сервиса.

Записываем файл и перезапускаем sudo systemctl restart apache2, либо sudo /etc/init.d/apache2 restart

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

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

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

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

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

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

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

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


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

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

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

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

ВАЖНО! Если вы на шаге 2.2 создали токен доступа для другого пользователя (у меня это пользователь ADS (СППР)), не для себя, самое время добавить этого пользователя в члены проекта. Добавлять его нужно с правами Maintainer:

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. Чтобы он увидел что сборочная линия уже есть, нужно слить ветку dev/101 в ветку master. Для этого необходимо создать запрос на слияние ветки dev/101 в ветку master. Сделаем это в разделе "Merge requests"

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

6.   Для настройки бегунов гитлаба устанавливаем его из консоли: sudo apt-get install gitlab-runner. Можете прочитать инструкцию по установке полностью. Я рекомендую, в целях демонстрации поступить проще, запустить только одного бегуна и не устанавливать его в качестве службы. Точнее служба будет создана и запущена сразу после установки её нужно отключить, по тем же причинам, по которым отключали и 1С:Предприятие – запускаемым файлам 1C требуется GUI.

1.   sudo systemctl disable gitlab-runner

2.   sudo systemctl stop gitlab-runner

3.  gitlab-runner register_

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





evgeniy@Ubuntu-VM2:~$ gitlab-runner register

Runtime platform                                    arch=amd64 os=linux pid=21329 revision=4c96e5ad version=12.9.0

WARNING: Running in user-mode.                     

WARNING: The user-mode requires you to manually start builds processing:

WARNING: $ gitlab-runner run                       

WARNING: Use sudo for system-mode:                 

WARNING: $ sudo gitlab-runner...                   

                                                  

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

http://Ubuntu-GLS/           

Please enter the gitlab-ci token for this runner:

GR1348941n6Epz2b-RuXWqtJ2Tp4P

Please enter the gitlab-ci description for this runner:

[Ubuntu-VM2]: DemoAM-runner

Please enter the gitlab-ci tags for this runner (comma separated):

build, convertation, gui-command, update                                                          

Registering runner... succeeded                     runner=GR134894

Please enter the executor: docker-ssh, parallels, shell, ssh, kubernetes, custom, docker, virtualbox, docker+machine, docker-ssh+machine:

shell

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

evgeniy@Ubuntu-VM2:~$

5.  В процессе регистрации бегун в каталоге ~/.gitlab-runner/ создаст конфигурационный файл config.toml, в нём нужно исправить параметр:
concurrent = 6
это означает количество параллельно исполняемых заданий. Запускаем:
evgeniy@Ubuntu-VM2:~$ gitlab-runner run

Runtime platform                                    arch=amd64 os=linux pid=22539 revision=4c96e5ad version=12.9.0

Starting multi-runner from /home/evgeniy/.gitlab-runner/config.toml...  builds=0

WARNING: Running in user-mode.                     

WARNING: Use sudo for system-mode:                 

WARNING: $ sudo gitlab-runner...                   

                                                  

Configuration loaded                                builds=0

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

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

6. После запуска бегуна в gitlab его должен увидеть (обновите страницу, раскройте секцию Runner’ы):
   

7.  Далее, необходимо установить несколько переменных окружения в разделе Settings-CI/CD-Variables, они есть в тексте сборочной линии в этапе StagesAndVariables:
# Переменные ниже должны быть определены на сервере сборки
#L_PLATFORM_1C:    '/opt/1C/v8.3.17-1549/x86_64/1cv8'  # Путь к запускаемому толстому клиенту Linux
#L_PLATFORM_1C_tc: '/opt/1C/v8.3.17-1549/x86_64/1cv8c' # Путь к запускаемому тонкому клиенту Linux
# Переменные ниже могут быть определены на сервере сборки
#CI_DEBUG_TRACE: 'true'

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

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

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

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

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

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

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