Girar/Development: различия между версиями
< Girar
Vitty (обсуждение | вклад) |
Vitty (обсуждение | вклад) |
||
Строка 31: | Строка 31: | ||
=== "Web-interface" === | === "Web-interface" === | ||
* В условиях существования "Персональных репозиториев" и "Дополнений к репозиториям" хочется иметь web-интерфейс для визуализации/поиска/etc. | |||
* Предусловием реализации является наличие "RESTful API" | |||
=== "Публичный build-service" === | === "Публичный build-service" === | ||
=== "Инфраструктура тестирования" === | === "Инфраструктура тестирования" === |
Версия от 00:15, 24 августа 2010
Abstract
Эта страница описывает актуальные задачи развития инфраструктуры Girar.
Цель
Развитие инфраструктуры Girar преследует следующие цели:
- Повышение качества пакетов, собираемых для Sisyphus и/или производных продуктов;
- Снижение нагрузки на майнтейнера пакета в Sisyphus и/или производных продуктах при выполнении рутинных операций;
- Создание майнтейнеру дополнительных возможностей автоматического/автоматизированного тестирования пакетов;
- Создание условий для разработки сторонних систем взаимодействия с инфраструктурой Girar
Задачи
"Персональный репозиторий"
Направление развитие относится к т.н. "Карманам".
- Основная решаемая задача: дать инструмент проведения масштабного эксперимента над Sisyphus или производным продуктом.
- Как будет работать: по команде пользователя будет создаваться срез указанного репозитория (клон) с выдачей инициатору прав суперпользователя. В дальнейшем над получившимся репозиторием производится необходимый эксперимент группой майнтейнеров и тестирующих пользователей.
- Ограничения: Для предотвращения ненужных форков время жизни "персональных репозиториев" должно быть ограничено.
"Дополнение к репозиторию"
Направление развитие относится к т.н. "Карманам".
- Основная решаемая задача: Долгоживущая сборка пакета (или группы пакетов) для Sisyphus или производного продукта без публикации результата. Получившийся результат должен постоянно оставаться совместимым с репозиторием (т.е., к примеру, должна производиться автоматическая пересборка дополнения при изменении его сборочной среды). Пример usecase-а для таких "дополнений": backport.
- Способ функционирования: Для каждого репозитория должен поддерживаться список существующих "дополнений" и их сборочные среды. При изменении репозитория должен формироваться список "дополнений", требующих пересборки и должна инициироваться фоновая их пересборка.
- Ограничения: Должны быть разумные причины существования подобных "дополнений" т.к. они требуют вычислительных ресурсов.
"RESTful API"
- Для взаимодействия сторонних информационных систем с Girar требуется наличие машинно-пригодного интерфейса взаимодействия. Предлагается разработать HTTP-шный интерфейс взаимодействия. В качестве формата данных предполагается использовать JSON.
- Замечание. Write-действия требуют аутентификации, а ssh-ключ не подходит для использования по HTTP. Предлагается реализовать возможность изменения (посредством ssh git.alt) пароля и включение/выключение write-доступа.
"Web-interface"
- В условиях существования "Персональных репозиториев" и "Дополнений к репозиториям" хочется иметь web-интерфейс для визуализации/поиска/etc.
- Предусловием реализации является наличие "RESTful API"