Differences between revisions 1 and 7 (spanning 6 versions)
⇤ ← Revision 1 as of 2011-06-11 12:23:12 →
Size: 1280
Editor: FrBrGeorge
Comment:
← Revision 7 as of 2011-07-01 16:52:11 → ⇥
Size: 5486
Editor: FrBrGeorge
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
=== Workflow ===
1. Импорт
 * Новых
  * настройка autobuild
  * Типовые watchfile для sf, gh, gc, g.a...
 * Подготовленных, из целевого хранилища (критерий выбора, массовость)
1. Синхронизация
 * с целевым хранилищем
 * ?с возможной devel-веткой
1. Проверка апстрима
 * универсальная, для разных схем репозитория (схему можно надумать из rules и autobuild.watch)
 * ?что умеет uscan?
1. Обновление исходников
 * универсальное, для разных схем репозитория
 * с исправлением спека, если обновление успешно
 * ?с созданием отдельной ветки
1. Сборка обновлённого пакета
 * правильный apt.conf
 * критерии успешности
 * со слиянием, если сборка успешна
1. Тестирование
 * ?маркировка тестированых
1. Отсылка в g.a и на сборку		 Общие понятия (на примере 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(количество сборок)`
 1. Робот не подписывает пакеты подписью майнтейнера

=== Описание Workflow ===
 * {i} требуется исследование
 * <!> ''может'' закончится неуспешно (текст после <!> описывает обработку неуспеха, по умолчанию -- останов + оповещение)
 * {2} второстепенное
==== Старт ====
 1. подготовка репозитория
  * {2} создание нового
   1. связывание нового репозитория с git.alt
   1. настройка autobuild
   1. создание минимального хранилища "версии 0"
   1. стартовая синхронизация и обновление исходников
   1. оформление пакета
  * импорт существующего
   1. настройка autobuild
   1. проверка синхронизации
 1. допуск к автосборке и публикация
Типовые `watchfile` для sf, gh, gc, g.a...
==== Синхронизация ====
 1. Синхронизация
  1. с целевым хранилищем
  1. {2} с devel-веткой
 1. Проверка апстрима
  1. генерация uscan-файла на основании шаблона (нужно для sf, gc и т. п.: они часто меняют формат доступа)
  1. выяснение апстримной версий <!>
   * несколько исходников
   * VCS
  1. выяснение текущей версии
   * несколько исходников
  1. сравнение версий (возможно, нестрогое) и допуск к обновлению
==== Обновление ====
 1. подготовка сборочной версии старых исходников (например, создание временной ветки)
 1. получение исходников из апстрим <!>
 1. обновление старых исходников новыми <!>
 1. модификация служебных файлов (*.spec, .gear/* ...)
 1. допуск к сборке (например, commmit + tag)
==== Сборка ====
 1. тестовая сборка сборочной версии <!>
 1. получение журнала сборки
 1. проверка качества сборки <!>
 1. публикация результатов тестовой сборки для тестирования

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

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

<<Anchor(homebrew)>>
=== Организация «домашней» сборки и тестирования ===
 * Доступ к бинарному репозиторию
 * Подготовка apt.conf
 * Сеанс автосборки
  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 16:52:11 by FrBrGeorge)