Girar/Development
Abstract
Эта страница описывает актуальные задачи развития инфраструктуры Girar. Задачи заносятся в bugzilla (продукт Infrastructure, компонент git.altlinux.org) как FR.
Цель
Развитие инфраструктуры Girar преследует следующие цели:
- Повышение качества пакетов, собираемых для Sisyphus и/или производных продуктов;
- Снижение нагрузки на майнтейнера пакета в Sisyphus и/или производных продуктах при выполнении рутинных операций;
- Создание майнтейнеру дополнительных возможностей автоматического/автоматизированного тестирования пакетов;
- Создание условий для разработки сторонних систем взаимодействия с инфраструктурой Girar
Задачи
"Результат сборки задания как репозиторий"
- Задача: обеспечение удобного способа тестирования test-only заданий
- Требуемые доработки:
- Предоставление собранных файлов как репозитория, пригодного для подключения как rpm-dir
- Короткий URL репозитория (например, http://git.altlinux.org/repo/21788/ i586 hasher)
"Персональный репозиторий-клон"
Направление развития относится к т.н. "Карманам".
- Основная решаемая задача: дать инструмент проведения масштабного эксперимента над базовым репозиторием (Sisyphus или производным продуктом).
- Как будет работать: по команде пользователя создаётся copy-on-write клон указанного базового репозитория с выдачей инициатору прав суперпользователя в пределах нового репозитория. В дальнейшем над получившимся репозиторием производится необходимый эксперимент группой майнтейнеров и тестирующих пользователей.
- Ограничения: Для предотвращения ненужных форков время жизни "персональных репозиториев-клонов" должно быть ограничено.
"Персональное дополнение к репозиторию"
Направление развития относится к т.н. "Карманам".
- Основная решаемая задача: Долгоживущая сборка пакета (или группы пакетов) для базового репозитория (Sisyphus или производного продукта) без публикации результата в базовом репозитории. Получившийся результат должен постоянно оставаться совместимым с базовым репозиторием (например, должна производиться автоматическая пересборка дополнения при изменении его сборочной среды). Пример usecase-а для таких "дополнений": backport.
- Способ функционирования: Для каждого базового репозитория должен поддерживаться список существующих "дополнений". При изменении репозитория должен формироваться список "дополнений", требующих пересборки и должна инициироваться их фоновая пересборка.
- Ограничения: Должны быть разумные причины существования подобных "дополнений", поскольку они требуют вычислительных ресурсов.
"RESTful API"
- Для взаимодействия сторонних информационных систем с Girar требуется наличие машинно-пригодного интерфейса взаимодействия. Предлагается разработать HTTP-шный интерфейс взаимодействия. В качестве формата данных предполагается использовать JSON.
- Замечание. Write-действия требуют аутентификации, а ssh-ключ не подходит для использования по HTTP. Предлагается реализовать возможность изменения (посредством ssh git.alt) пароля и включение/выключение write-доступа.
"Web-interface"
- В условиях существования "Персональных репозиториев" и "Дополнений к репозиториям" хочется иметь web-интерфейс для визуализации/поиска/etc.
- Предусловием реализации является наличие "RESTful API". Также потребуется завести такие сущности как "теги" и "описания" для караманов любого вида и заданий.
"Публичный build service"
- Основная решаемая задача: Создание стороннему прикладному разработчику (не являющемуся разработчиком Sisyphus) возможности собрать своё приложение для Sisyphus и/или производного продукта. Необходимо обеспечить автоматическую сборку залитого пакета под определённый набор репозиториев (автоматический бекпорт). Предполагается, что данная возможность будет доступна всем самозарегистрировавшимся через web-интерфейс "Публичного build service".
- Способ функционирования: Функционирует как "Персональное дополнение к репозиторию" в отдельной (без разделения unix-пользователей) сборочнице.
"Инфраструктура тестирования"
- Изначальная постановка задачи: ab@
- Задача: Существует некоторое количество сложных пакетов, тестирование которых требует наличие нескольких многомашинных конфигураций (пример - samba). Далеко не каждый майнтейнер обладает подобной собственной инфраструктурой для проведения полноценного тестирования. Требуется разработать систему создания/хранения/исполнения подобных многомашинных (виртуальных) окружений.
- Способ функционирования: требует продумывания. Пока ясно, что требуются возможности по:
- созданию
- хранению
- исполнению
- связыванию
виртуальных машин. Требуется учесть, что во многих конфигурациях потребуется наличие виртуальных машин с ОС, отличными от ALT Linux (win, другие дистрибутивы,...) altbug:23941
"Модуль ядра из шаблона"
- Изначальная постановка задачи: sin@
- Задача: На текущий момент сборка или обновление модуля для заданного ядра требует кропотливых действий:
- собрать исходники модуля в отдельный noarch-пакет вида kernel-source-%module_name;
- создать или нбновить шаблон для сборки модуля в виде отдельной ветки для заданного репозитория (например, template/%module_name/%repo_name);
- создать или обновить текущую ветку модуля (например, kernel-modules-%module_name-%kernel_flavour/%repo_name), при этом ветки шаблонов и модулей обычно хранятся в одном репозитории kernel-modules, а для для создания и обновления веток модулей используются скрипты из пакета/репозитория kernel-build-tools;
- после генерации веток с модулями и соответствующих, подписанных gpg-подписью, тегов эти объекты отправляются в удалённый репозиторий;
- отправленные изменения добавляются на сборку, как обычные подзадачи по тегу (команда ssh git.alt task add package_name tag_name).
Кроме сложности алгоритма существует ряд неудобств в связи с выяснением текущей версии и релиза заданного ядра (последняя сборка пакета kernel-image-%kernel_flavour в репозитоии), обновлением последней сборки модуля (ветка %repo_name в репозитории /gears/k/kernel-module-%module_name-%kernel_flavour), использованием скриптов kernel-build-tools. Требуется упростить процесс сборки модуля путём создания более сложных клиентских скриптов, либо дополнительных команд на сервере. Потенциально вся необходимая информация может доступна на клиентах, но их применение чревато "гонками" (во время формирования задачи, пакеты с модулями и ядром могут быть обновлены). Тем не менее, чисто клиентский вариант не потребует действий по созданию коммитов на сервере, которые не смогут быть подписаны непосредственно пользователем.
- Способ функционирования: требует от скриптов на сервере наличия сведений о состоянии пакетов (имя, версия, релиз) во время формирования задачи.
Параллельная сборочница
Основная страница - Girar/Parallel.