Различия между версиями 4 и 5
⇤ ← Версия 4 от 2011-06-18 16:37:56 →
Размер: 3528
Редактор: FrBrGeorge
Комментарий:
← Версия 5 от 2011-06-18 17:18:36 → ⇥
Размер: 4487
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 9: Строка 9:
Принципы:
 1. Робот не засоряет репозиторий на git.alt
  * Константное число веток
  * `Число тегов=O(количество сборок)`
 1. Робот не подписывает пакеты подписью майнтейнера
Строка 10: Строка 16:
 * ./ автоматическое  * {*} автоматическое
Строка 23: Строка 29:
 1. ./ Синхронизация  1. {*} Синхронизация
Строка 25: Строка 31:
  1. {2} с devel-веткой <!> (
 1. ./ Проверка апстрима		   1. {2} с devel-веткой <!>
 1. {*} Проверка апстрима
Строка 33: Строка 39:
 1. ./ Обновление исходников  1. {*} Обновление исходников
Строка 39: Строка 45:
 1. ./ Сборка обновлённого пакета
  1. Тестовая сборка <!>
   * «Домашняя» (см. [[#homebrew|Инфраструктура «домашней» сборки]])
    * последовательность сборки
    * нстройка apt.conf
   * критерии успешности
  1. Втягивание маркированных исходнков		  1. {*} Сборка обновлённого пакета
  1. тестовая сборка сборочной версии <!>
   * «Домашняя» (см. [[#homebrew|Организация «домашней» сборки]])
   * {i} посредством git.alt
  1. получение журнала сборки
  1. проверка качества сборки <!>
  1. публикация результатов тестовой сборки для тестирования
   * {i} если сборки была на git.alt
Строка 47: Строка 54:
  * {i} маркировка тестированных   * {*} получение бинарных пакетов для тестирования
  * установка пакетов
  * тестирование
  * маркировка оттестированных пакетов
Строка 49: Строка 59:
  1. подготовка рабочей версии обновлённых исходников (например, merge из временной ветки)
  1. отсылка рабочей версии в репозиторий
  1. запуск сборочницы


=== Структура комплекта сценариев ===
Строка 51: Строка 67:
=== Инфраструктура «домашней» сборки === === Организация «домашней» сборки ===
Строка 56: Строка 72:
=== Следствия === == Следствия ==

Огромные человекоподобные роботы

Workflow

Общие понятия (на примере git.alt):

Целевое хранилище
название ветки в /gears (sisyphus)
Пакет
git-репозиторий на git.alt
Схема репозитория

способ организации на git.alt (http://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_gear)

Имя пакета

название src.rpm ( => имени репозитория в /gears)

Принципы:

  1. Робот не засоряет репозиторий на git.alt
    • Константное число веток

    • Число тегов=O(количество сборок)

  2. Робот не подписывает пакеты подписью майнтейнера

Действия:

  • {*} автоматическое

  • {i} требуется исследование

  • <!> может закончится неуспешно (текст после <!> описывает обработку неуспеха, по умолчанию -- останов + оповещение)

  • {2} второстепенное

Общий workflow:

  1. Добавление пакета
    • Создание нового репозитория
      • настройка autobuild
      • создание минимального хранилища "версии 0"
      • стартовое обновление исходников
    • Импорт существующего репозитория

      • {2} автоматическая конвертация

    • Типовые watchfile для sf, gh, gc, g.a... ({i} * типовые репозитории?)

  2. {*} Синхронизация

    1. с целевым хранилищем

    2. {2} с devel-веткой <!>

  3. {*} Проверка апстрима

    1. выяснение апстримной версий <!>

      • несколько исходников
      • VCS
    2. выяснение текущей версии
      • несколько исходников
    3. сравнение версий (возможно, нестрогое)

  4. {*} Обновление исходников

    1. подготовка сборочной версии старых исходников (например, создание временной ветки)

    2. получение исходников из апстрим <!>

    3. обновление старых исходников новыми <!>

    4. модификация служебных файлов (*.spec, .gear/* ...)
    5. маркировка (например, commmit + tag)

  5. {*} Сборка обновлённого пакета

    1. тестовая сборка сборочной версии <!>

    2. получение журнала сборки

    3. проверка качества сборки <!>

    4. публикация результатов тестовой сборки для тестирования

      • {i} если сборки была на git.alt

  6. Тестирование

    • {*} получение бинарных пакетов для тестирования

    • установка пакетов
    • тестирование
    • маркировка оттестированных пакетов
  7. Отсылка в g.a и на сборку
    1. подготовка рабочей версии обновлённых исходников (например, merge из временной ветки)
    2. отсылка рабочей версии в репозиторий
    3. запуск сборочницы

Структура комплекта сценариев

Организация «домашней» сборки

  • Запуск по cron .... TODO
  • Доступ к бинарному репозиторию
  • Подготовка apt.conf
  • ...

Следствия

  • Разделение майнтейнера на активного пользователя (тестера) и сборщика. Разумеется, лучше в одном лице, но...
  • Внешнее автоматическое тестирование

FrBrGeorge/HumanlikeRobots (последним исправлял пользователь FrBrGeorge 2011-07-01 16:52:11)