Gitlab Runner для распаковки e365

В данной статьей мы расскажем о том, как с можно хранить решения e365 в виде исходных кодов.
С помощью утилиты elma365pm можно экспортировать решение со стенда, распаковать файл. Эти две операции помогут нам настроить классический процесс код-ревью. План следующий - разработчик решения выгружает со стенда файл экспорта *.e365, закидывает коммит с этим файлом на git-сервер. Далее на сервере автоматически срабатывает автоматизация, которая предоставляет нам доступ к исходным кодам сценариев.
Установка Gitlab Runner
Для установки Gitlab Runner на машине, предназначенной для этого, выполните следующие команды:

Код:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

и

Код:

apt-get install gitlab-runner

Для регистрации Gitlab Runner зайдите в аккаунт администратора на вашем Gitlab, в левом верхнем углу нажмите на кнопку Menu, в выпадающем списке выберите Groups>Create group





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

• Зайдите в группу, также из Menu > Groups > Название вашей группы. В меню слева выберите CI/CD > Runners

• В новом окне в правом верхнем углу выберите Register new runner, в выпадающем меню скопируйте токен для нового раннера, он вам скоро понадобится.

• Вернитесь в консоль на ВМ и введите команду:

Код:

sudo gitlab-runner register

В процессе регистрации необходимо будет задать несколько параметров:

• Please enter the gitlab-ci coordinator URL (e.g. https://example.com) - укажите адрес вашего Gitlab инстанса
• Please enter the gitlab-ci token for this runner - введите токен для раннера, скопированный ранее.

• Please enter the gitlab-ci description for this runner - можете оставить по умолчанию, либо ввести название вашего раннера.
• Please enter the gitlab-ci tags for this runner (comma separated) - в нашем случае можно оставить пустым, тут предлагается ввести теги для раннера, по которым он будет выполнять определенные работы, в данном решении не используется
• Enter optional maintenance note for the runner - также оставляем пустым в нашем случае, здесь заполняется информация для разработчиков
• Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell - пишем docker
• Please enter the Docker image - дефолтный образ для докера, можете выбрать любой, например alpine:latest, это все равно в последствии перепишется в конфигурационных файлах.

Настройка Gitlab Runner

• Для удобства создадим проект, в котором будет храниться основной конвейер:

В данном случае проект называется Main Pipeline. Его структура:



Файл с инструкциями назовем .gitlab-ci.yml со следующим содержимым

Код:

stages:
    - unpack
include:
    - "/templates/.unpack_runner.yml"
image:
    alpine

Мы задаем названия этапов для нашего пайплайна. Папка templates будет содержать этапы, сейчас там будет находиться один файл .unpack_runner.yml

Содержимое файла .unpack_runner.yml (файл приложен в статье)

Код:

unpack:
    image:
        deconstruct365/elma365:latest
    stage: unpack
    allow_failure: true
    script:
        - apk update && apk add git
        - git config --global user.name "$CI_ROBOT_NAME"
        - git config --global user.email "$CI_ROBOT_EMAIL"
        - git remote set-url origin $GITLAB_PROJECT_PATH
        - cp /unpacker/elma365pm . && cp /unpacker/unpacker.py .
        - python3 ./unpacker.py
        - rm elma365pm unpacker.py
        - git add --all
        - git commit -m "commit from robot"
        - git push -f origin HEAD:$CI_COMMIT_BRANCH
    rules:
        - if: $CI_COMMIT_BRANCH =~ /.*dev.*/ &&
              $CI_COMMIT_MESSAGE !~ /.*robot.*/
          exists:
              - "**/*.e365"

Переменные окружения
Также необходимо определить переменные окружения, которые будут использоваться в процессе запуска работ раннера. Для этого на странице с проектом, в левом меню выбираем Settings > CI/CD


В новом окне раскрываем выпадающее меню Variables.


Через кнопку Add variable добавляем необходимые переменные:



DOCKER_AUTH_CONFIG - для того, чтобы получить это значение, на машине, где установлен докер, введите docker login, далее введите свои логин и пароль от Docker Hub’а. После уведомления, что логин успешен, перейдите в корневую директорию root-пользователя, там найдите папку .docker, а в ней файл config.json. Скопируйте содержимое файла и вставьте в поле Value в окне с добавлением новой переменной.
Далее также необходимо добавить переменные окружения на уровне группы. Для этого зайдите на главную страницу вашей группы, и в левом меню выберите Settings > CI/CD



Также, как и ранее, раскройте выпадающее меню Variables, и добавьте переменные:
CI_ROBOT_EMAIL - для удобства, лучше создать отдельного пользователя на вашем gitlab и выдать ему права администратор. Он будет играть роль робота, который делает пуши и прочую логику, связанную с ветками. В данной переменной лежит его email.
CI_ROBOT_PASSWORD - пароль от аккаунта вашего робота на gitlab.
CI_ROBOT_NAME - имя аккаунта вашего робота на gitlab.
GITLAB_PROJECT_PATH - вставьте ровно это, заменив только hostname вашего gitlab-инстанса: https://$CI_ROBOT_NAME:$CI_ROBOT_PASSWORD@<url-вашего-gitlab>/$CI_PROJECT_PATH.git
Теперь нужно подключить наш раннер к проекту. Так как мы сделали его групповым, он будет доступен для всех проектов, относящимся к группе. Из главного окна своего проекта снова заходим в раздел Settings > CI/CD в левом меню. Далее открываем выпадающее меню Runners.


Групповой раннер будет по умолчанию подключен к проекту, чтобы его отключить, нажмите Disable group runners


Проверка работы
Создадим новый проект в нашей группе, назовем его Test. В корне проекта создаем файл .gitlab-ci.yml со следующим содержимым:

Код:

include:
    - project: "elma365/main-pipeline"
      file: ".gitlab-ci.yml"

elma365 - название группы, которую мы создали в начале
main-pipeline - название проекта, в котором лежат настройки. Мы его создали на этапе настроек Gitlab Runner
В этом файле мы ссылаемся на наш проект с настройками и наш файл с этапами пайплайна.
Заливаем файл .gitlab-ci.yml в ветку master(или main).
Из ветки master создаем новую ветку som_dev_brach. Экспортируем из ELMA365 разработанное решение, в нашем случае файл test.e365. После этого заливаем его в нашу ветку some_dev_branch, как видно на скриншоте ниже. Раннер настроен таким образом, что срабатывает при определенных условиях, в данном случае, на стадии unpack, раннер видит коммит, и сравнивает название ветки на соответствие подстроке dev по регулярному выражению:



Также напротив коммита можно увидеть значок :



Это означает, что условия совпали и раннер начал свою работу. Если нажать на этот значок, можно перейти на страницу с информацией о запущенном пайплайне:



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



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


Папка test-unpacked содержит распакованную версию нашего решения