Differences between revisions 4 and 7 (spanning 3 versions)
Revision 4 as of 2011-06-18 13:37:56
Size: 3528
Editor: FrBrGeorge
Comment:
Revision 7 as of 2011-07-01 13:52:11
Size: 5486
Editor: FrBrGeorge
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
=== Workflow ===
Line 9: Line 8:
Действия:
 * ./ автоматическое
 Допуск (к некоторому действию):: маркировка пакета для того, чтобы робот, выполняющий данное действие, выполнил его
Принципы:
 1. Робот не засоряет репозиторий на git.alt
  * Константное число веток
  * `Число тегов=O(количество сборок)`
 1. Робот не подписывает пакеты подписью майнтейнера

=== Описание Workflow ===
Line 14: Line 19:
Общий workflow:
 1. Добавление пакета
  * Создание нового репозитория
   * настройка autobuild
   * создание минимального хранилища "версии 0"
   * стартовое обновление исходников
  * Импорт существующего репозитория
   * {2} автоматическая конвертация
  * Типовые watchfile для sf, gh, gc, g.a... ({i} * типовые репозитории?)
 1. ./ Синхронизация
==== Старт ====
 1. подготовка репозитория
  * {2} создание нового
   1. связывание нового репозитория с git.alt
   1. настройка autobuild
   1. создание минимального хранилища "версии 0"
   1. стартовая синхронизация и обновление исходников
   1. оформление пакета
  * импорт существующего
   1. настройка autobuild
   1. проверка синхронизации
 1. допуск к автосборке и публикация
Типовые `watchfile` для sf, gh, gc, g.a...
==== Синхронизация ====
 1. Синхронизация
Line 25: Line 35:
  1. {2} с devel-веткой <!> (
 1. ./ Проверка апстрима
  1. {2} с devel-веткой
 1. Проверка апстрима
  1. генерация uscan-файла на основании шаблона (нужно для sf, gc и т. п.: они часто меняют формат доступа)
Line 32: Line 43:
  1. сравнение версий (возможно, нестрогое)
 1. ./ Обновление исходников
  1. подготовка сборочной версии старых исходников (например, создание временной ветки)
  1. получение исходников из апстрим <!>
  1. обновление старых исходников новыми <!>
  1. модификация служебных файлов (*.spec, .gear/* ...)
  1. маркировка (например, commmit + tag)
 1. ./ Сборка обновлённого пакета
  1. Тестовая сборка <!>
   * «Домашняя» (см. [[#homebrew|Инфраструктура «домашней» сборки]])
    * последовательность сборки
    * нстройка apt.conf
   * критерии успешности
  1. Втягивание маркированных исходнков
 1. Тестирование
  * {i} маркировка тестированных
 1. Отсылка в g.a и на сборку
  1. сравнение версий (возможно, нестрогое) и допуск к обновлению
==== Обновление ====
 1. подготовка сборочной версии старых исходников (например, создание временной ветки)
 1. получение исходников из апстрим <!>
 1. обновление старых исходников новыми <!>
 1. модификация служебных файлов (*.spec, .gear/* ...)
 1. допуск к сборке (например, commmit + tag)
==== Сборка ====
 1. тестовая сборка сборочной версии <!>
 1. получение журнала сборки
 1. проверка качества сборки <!>
 1. публикация результатов тестовой сборки для тестирования

См. ниже [[#homebrew|Организация «домашней» сборки]]
==== Тестирование ====
 1. получение бинарных пакетов для тестирования
 1. установка пакетов
 1. тестирование <!>
 1. маркировка оттестированных пакетов
==== Размещение в хранилище ====
 1. подготовка целевой версии обновлённых исходников (например, merge из временной ветки)
 1. публикация целевой версии
 1. запуск сборочницы целевого репозитория

=== Структура комплекта сценариев ===
'''TODO'''
Line 51: Line 71:
=== Инфраструктура «домашней» сборки ===
 * Запуск по cron .... TODO
=== Организация «домашней» сборки и тестирования ===
Line 55: Line 74:
 * ...
=== Следствия ===
 * Сеанс автосборки
  1. синхронизация всех пакетов
  1. выявление и импорт ''новых'' подготовленных к автосборке пакетов
  1. обновление допущенных к обновлению пакетов
  1. сборка допущенных допущенных к сборке пакетов
  1. публикация успешно собравшихся пакетов
 * {2} Запуск сеанса cron
'''TODO''': диаграмма состояний
== Следствия ==

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

Общие понятия (на примере 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. Робот не подписывает пакеты подписью майнтейнера

Описание Workflow

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

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

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

Старт

  1. подготовка репозитория
    • {2} создание нового

      1. связывание нового репозитория с git.alt
      2. настройка autobuild
      3. создание минимального хранилища "версии 0"
      4. стартовая синхронизация и обновление исходников
      5. оформление пакета
    • импорт существующего
      1. настройка autobuild
      2. проверка синхронизации
  2. допуск к автосборке и публикация

Типовые watchfile для sf, gh, gc, g.a...

Синхронизация

  1. Синхронизация
    1. с целевым хранилищем
    2. {2} с devel-веткой

  2. Проверка апстрима
    1. генерация uscan-файла на основании шаблона (нужно для sf, gc и т. п.: они часто меняют формат доступа)
    2. выяснение апстримной версий <!>

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

Обновление

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

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

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

Сборка

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

  2. получение журнала сборки
  3. проверка качества сборки <!>

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

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

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

  1. получение бинарных пакетов для тестирования
  2. установка пакетов
  3. тестирование <!>

  4. маркировка оттестированных пакетов

Размещение в хранилище

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

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

TODO

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

  • Доступ к бинарному репозиторию
  • Подготовка apt.conf
  • Сеанс автосборки
    1. синхронизация всех пакетов
    2. выявление и импорт новых подготовленных к автосборке пакетов

    3. обновление допущенных к обновлению пакетов
    4. сборка допущенных допущенных к сборке пакетов
    5. публикация успешно собравшихся пакетов
  • {2} Запуск сеанса cron

TODO: диаграмма состояний

Следствия

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

FrBrGeorge/HumanlikeRobots (last edited 2011-07-01 13:52:11 by FrBrGeorge)