Протестировал две российские системы работы с кодом. Что у меня (не) получилось28.02.2025 07:00

Из тестового пайплайна — в тестовые устройства

Как специалисту из области DevOps мне необходимо часто использовать различные инструменты автоматизации для решения рабочих задач. А еще я стараюсь применять некоторые механизмы в своих пет-проектах. Например, когда я занялся разработкой на ОС «Аврора», одной из первых насущных задач стала настройка пайплайна сборки приложений. В исходной версии использовал GitLab, т. к. активно пользовался им и завел несколько виртуальных машин для сборок в проекты. Однако в последнее время знакомые и коллеги начали нередко заводить проекты в других сервисах. Мне стало интересно — можно ли найти на российском рынке что-то конкурентоспособное? Давайте разберемся!

Введение

GitFlic — альтернатива GitLab, которая была основана в 2020 году небольшой командой людей, а в 2023 вошла в состав ГК «Астра». На сегодняшний день сервис доступен как в веб-версии, так и в качестве self-hosted решения. Имеет базовую функциональность системы контроля версий Git, возможность реализовать систему CI/CD, а также может использоваться в качестве хранилища для артефактов сборок maven, pypi и т. д.

gitflic.ru

GitVerse — альтернатива GitHub. Проект появился в 2023 году, а в прошлом году открыл тестовый доступ. Также имеет систему контроля Git, CI/CD, хранилище пакетов. На днях также в бету выпустили GigaIDE Cloud — облачную среду разработки, интеграрованную с GitVerse.

gitverse.ru

Что я хочу от этих сервисов? Помимо хранения кода и возможности поделиться им с другими, мне требуются пайплайны сборки и доставки приложений. Рассмотрим, как создать сборку мобильного приложения на базе представленных систем.

Рассматриваемые в этой статье примеры относятся к приложениям Qt, разработанным в Aurora IDE.

Подготовка среды

В первую очередь подготовим стенд, на котором будем проводить эксперименты. Это может быть ваш компьютер, отдельно стоящий системный блок, виртуальный или выделенный сервер. Для работы предпочитаю использовать Ubuntu server LTS. Вы также можете повторить на любой ОС, включая Windows, macOS или Astra. Рассмотрим два варианта для сборки приложений для целевой ОС.

Приводимые далее команды и установочные скрипты можно выполнить в момент создания сервера. Для этого укажите в разделе «Автоматизация» все, что хотите чтобы было готово.

Platform SDK

PSDK (Platform Software Development Kit) представляет собой набор компонентов, позволяющий разрабатывать и собирать приложения под целевую ОС. В него входят:

Сhroot — контейнер, содержащий минимально необходимые конфигурации для сборки;
Tooling — набор утилит, компилятора и библиотек;
Target — базовый образ «Авроры» под каждую платформу.

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

Для работы с PSDK необходимо создать пользователя. Он будет отвечать за среду сборки, а еще из-под него будем запускать агентов типа shell. Для этого в соответствии с инструкцией разработчика создаем пользователя и ставим минимально необходимые программы:

sudo apt install -y openjdk-21-jre-headless unzip cowsay git curl
CI_USER=apsdk
sudo useradd --comment 'Aurora PlatformSDK' --create-home $CI_USER --shell /bin/bash
sudo passwd --delete $CI_USER
sudo usermod -aG sudo $CI_USER
echo "$CI_USER ALL=(ALL:ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$CI_USER
sudo rm -f /home/$CI_USER/.bash_logout

Следующим этапом необходимо установить сам PSDK. Самый простой и быстрый вариант — скачать скрипт установки, рекомендуемый ОМП.

curl -O https://sdk-repo.omprussia.ru/sdk/documents/Platform_SDK/CI/psdk_install-master.zip
unzip psdk_install-master.zip
psdk_install-master/install_aurora_psdk.sh \
  --input-url https://sdk-repo.omprussia.ru/sdk/installers/5.1.3/5.1.3.85-release/AuroraPSDK \
  --allowed-targets aarch64,armv7hl \
  --custom-prompt-prefix CI_PSDK

Актуальную версию PDSK можно посмотреть в репозитории.

После установки можно проверить работоспособность следующей командой:

apsdk@blade-runner:~$ $HOME/AuroraPlatformSDK/sdks/aurora_psdk/sdk-chroot \
  sdk-assistant list

Теперь необходимо загрузить скрипт сборки. Мне удобнее, чтобы он был в одном месте, чем добавлять его заново в каждый проект. Выполним следующие команды:

mkdir build && git clone https://gist.github.com/a3fed46f6ea14c6c79ff212d14477742.git build
chmod +x build/aurora_build.sh

Для проверки скачайте тестовый проект, перейдите в папку с ним и запустите следующую команду для сборки. После успешного выполнения в папке RPMS будет собранное приложение.

/home/apsdk/AuroraPlatformSDK/sdks/aurora_psdk/sdk-chroot \
  /home/apsdk/build/aurora_build.sh -n TinyBrowser \
  -v 5.1.3 -r 85-MB2 -t aarch64
ls TinyBrowser/RPMS

Docker AppTool

AppTool — кросс-компилятор, предоставляемый взамен mb2 и sb2. Распространяется в соответствующем контейнере и может быть использован для сборки проектов вместо PSDK.

Контейнер с AppTool отлично показывает себя на процессорах M1, решая проблему пользователей по сборке приложений под целевую ОС.
AppTool позволяет собирать приложения для версии ОС >= 5. Для 4 Авроры используйте Platform SDK.

Для установки требуется сначала установить Docker на целевую машину, если он еще не установлен. Далее необходимо скачать актуальный образ командой:

docker pull hub.omp.ru/public/sdk-build-tools:latest

Вместо latest можно указать существующую необходимую версию среды. После этого можно проверить работу, вызвав, например, справку по сборочному инструменту командой:

docker run --rm hub.omp.ru/public/sdk-build-tools apptool build -h

Если все сработало, то можно собрать проект, используя следующую конструкцию:

git clone https://gitlab.com/omprussia/examples/TinyBrowser.git
cd  TinyBrowser
docker run -it --rm -u `id -u`:`id -g` \ 
  -v $PWD:/project -w /project \ 
  hub.omp.ru/public/sdk-build-tools \
  apptool build --srcdir /project --aarch64
ls RPMS

На выходе в папке RPMS также появится собранный файл, готовый к установке на устройство.

Настройка раннеров

Если требуется использовать PSDK, то «бегунов» необходимо настраивать и запускать c типом shell от ранее созданного пользователя apsdk. Инструкция по созданию и регистрированию раннера для shell GitFlic доступна в документации. Есть также инструкция для shell GitVerse.

На момент написания статьи GitFlic в публичной версии предлагает регистрацию раннеров только в рамках компании или в self-hosted версии сервиса. Что ж, создаем компанию, переходим в раздел Настройки → Агенты CI/CD и копируем токен.

На стороне сервера для настройки Docker-раннера в GitFlic необходимо скачать и распаковать последний релиз раннера. Далее в docker-compose.yaml пропишите ваш URL и токен из настроек. По умолчанию это https://coordinator.gitflic.ru/-/runner/registration. Последний этап — запуск командой:

docker-compose up -d –build

Если все правильно сделали, то появится раннер в соответсвующем разделе

GitVerse же предоставляет возможность добавить локальный раннер в любой проект. Для этого в настройках репозитория необходимо включить CI/CD, обновить настройки и перейти в появившийся раздел Раннеры:

Копируем полученный токен и в пару кликов запускаем раннер:

docker pull gitverse.ru/gitverse/act-runner:3.0.2
docker run \
      -v /var/run/docker.sock:/var/run/docker.sock \
      -e RUNNER_REGISTRATION_TOKEN=${VERSE_TOKEN} \
      --name gitverse_runner -d \
      gitverse.ru/gitverse/act-runner:3.0.2

Здесь -${VERSE_TOKEN} — ваш токен из настроек.

Еще один успешно добавленный раннер, но уже в gitverse

Время CI/CD

Далее приведены примеры пайплайнов с использованием Docker-раннеров. Исходные коды для ваших экспериментов оставил в открытом доступе: gitflic, gitverse.

Gitflic

Как упоминалось ранее, GitFlic в пайплайнах похож на GitLab. Пайплайн для него перенес из своего текущего репозитория с некоторыми доработками. Рассмотрим, как работает простая сборка приложения.

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

include:
  - project:
     project_path: 'voryabchevsky/aurora_ci
     ref: main
     file:
       - 'build_qt_apptool.yml' #использовать docker runner

Пока подготавливал статью возникла проблема с ключевым словом include и одновременно условием по наличию тега (версия сервиса 3.5.2). После фиксации бага — укажу апдейт в этом блоке.

Далее описываем этапы, которые будут выполняться: установка версии, сборка и публикация артефактов.

stages:
  - set_version
  - build_qt

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

 stage: set_version
 rules:
   - if: $CI_COMMIT_TAG
 scripts:
   - echo "Сборка $CI_COMMIT_TAG"
   - 'sed -i -e "s/Version:.*/Version: $CI_COMMIT_TAG/g" rpm/*.spec'
 cache:
   paths:
     - rpm/

Следующий этап — сборка. Он полностью описан в файле build_qt_apptool.yml и используется для сборки с помощью раннера типа Docker. В темплейте описаны основные действия: выбор образа контейнера для сборки, кэшируемые директории, скрипт сборки и где будут находятся артефакты.

# Основной скрипт сборки приложения и извлечения артефактов
.build_qt:
 image: hub.omp.ru/public/sdk-build-tools
 cache: # используется кэш с файлами spec, где указана версия приложения
   paths:
    - rpm/
 scripts:
   - apptool build -s $(find rpm -name "*.spec") --$ARCH --nosign –-novalidate
 artifacts:
   name: $CI_COMMIT_REF_NAME-$CI_PROJECT_NAME-$ARCH
   paths:
    - RPMS/*.rpm

Сейчас поддерживается две архитектуры телефонов: aarch64 (например, Масштаб Т1) и armv7hl (например, Fplus R570E). Для них и будем выполнять сборку:

# Сборка актуальные архитектуры
build_qt_aarch64:
 stage: build_qt
 variables:
   ARCH: aarch64
 extends: .build_qt

 build_qt_armv7hl:
 stage: build_qt
 variables:
   ARCH: armv7hl
 extends: .build_qt

После выполнения указанного пайплайна файлы можно скачать из соответствующей вкладки с артефактами:

Успешное выполнение с готовыми артефактами

GitVerse

Если GitFlic копирует поведение GitLab, то GitVerse — GitHub. К сожалению, на момент написания статьи часть функционала GitVerse работала некорректно. Что ж, придется пока что копировать и изменять пайплайн во всех проектах, где он может пригодиться.

В середине февраля подготовил обращение в техподдержку и багтрекер, но ответ пока не получил. Когда будет ответ, укажу информацию в апдейте в статье и выложу примеры кода в репозиторий GitVerse.

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

name: Сборка Qt проекта для Аврора ОС
on:
  push:

Далее перечисляются работы и их параметры выполнения. Первая будет подготовка и сборка проекта. Для нее выбираю контейнер с apptools и монтирую volume, в который будут складываться собранные приложения.

jobs:
  build:
    name: Подготовка и сборка проекта
    runs-on: ubuntu-latest
    container: 
      image: hub.omp.ru/public/sdk-build-tools
      volumes:
        - releases:/releases

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

  steps:
    - name: Клонирование репозитория
      run: git clone https://${{ gitverse.token }}@gitverse.ru/${{ gitverse.repository }}.git .
    - name: Установка тега
      run: |
        echo ${{ gitverse.ref_name }} 
        SPEC=$(find rpm -name "*.spec")
        mv ${SPEC} ${SPEC}1
        sed 's/Version:.*/Version: ${{ gitverse.ref_name }}/g' ${SPEC}1> ${SPEC}

Далее запускается сборка приложения. Две архитектуры — две задачи. После выполнения последней копируем все файлы из директории с результатами работы в ранее примонтированный раздел:

  - name: Сборка aarch64
    run: |
      apptool build -s $(find rpm -name *.spec) --aarch64 
  - name: Сборка armv7hl
    run: |
      apptool build -s $(find rpm -name *.spec) --armv7hl 
      cp RPMS/* /releases

На этом этапе приложение собрано и также ожидает своей публикации.

Публикация приложения

Итак, приложение собирается и отлично работает. Предположим, что вы его полностью протестировали (или даже подключили джобу с автотестами) и теперь хотите поделиться им со всеми пользователями. Сделать это можно, оставив архив с приложением в разделе Релизы выбранного вами сервиса. Например, так:

Однако, если вы публикуете его в каком-либо магазине приложений, то можно сделать и автоматическую доставку обновленной версии до него. Подробная инструкция по публикации в Play Market и AppGallery есть в соответствующей статье.

Интересный нюанс: в GitVerse пока что не реализовано хранение артефактов. Рассмотрим, что нужно добавить в пайплайн для выгрузки артефактов, например в S3-хранилище. Оно также может иметь веб-интерфейс с доступом для пользователей или являться частью сайта и отдавать файлы через API.

Предварительно на сервер, где запущены раннеры, я добавил файлы config и credentials. В них я указал параметры подключения к объектному хранилищу. Эту папку и раздел с релизами монтирую к контейнеру с aws-cli. Далее копирую все артефакты в предварительно подготовленный контейнер.

 publish:
    name: Публикация файлов
    runs-on: ubuntu-latest
    container:
      image: amazon/aws-cli
      volumes:
        - /srv/aws:/root/.aws
        - releases:/releases
    steps:
      - name: Публикация в S3 
        run: aws s3 cp /releases s3://aurora-releases/ --recursive

Эту джобу необходимо добавить в конец файла с пайплайном. После выполнения всех действий, файлы можно скачать из веб-интерфейса хранилища:

Заключение

Обе среды предоставляют систему хранения кода и документации, управления проектами и автоматизацией. Но им еще предстоит дорабатываться, так как сейчас некоторая функциональность не реализована достаточно удобно и качественно или отсутствует. Например, возникают сложности при импорте шаблонов или отсутствует аналог github gist. Но меня радует, что разработчики активно вносят исправления в свои продукты, учитывают мнения и пожелания своих пользователей, оказывают техподдержку и активно развивают документацию.

GitFlic сейчас выглядит более развитым, но добавление раннеров только в «организацию» — для меня не самый удобный вариант. Возможно, попробую self-hosted решение. GitVerse — более молодой продукт, который активно дорабатывается и добавляет требуемый функционал.

Как представителю DevOps, мне важно иметь надежные инструменты для автоматизации рабочих процессов. И хотя пока ни один из рассмотренных сервисов не удовлетворяет моим требованиям на 100%, я все же верю, что развитие будет продолжаться и в будущем мы получим более широкий спектр функций.