Предлагаю обсудить вопрос доработки сборочницы таким образом, что бы все события, происходящие в ней могли инициировать процессы как в самой сборочнице, так и в сопутствующих системах (webery, repodb, bugzilla, watch, repocop и тестирование пакетов в стабильные репозитории) Что хочется получить: возможность сопутствующим системам узнать о том, что в сборочной системе (и рядом стоящих сервисах) произошли какие-то изменение. Например: - добавлено/удалено задание - добавлено/удалено подзадание - задание стало разделяемым - изменилось описание (комментарий) к заданию) - заданию/подзаданию дали/отозвали approve/disapprove - статус задания изменился (FAILED/DONE/EPERM/PENDING/BUILDING и т.д.) - ACL пакета изменился - выложен репозиторий в публичное место (на наш ftp) т.е. - любое событие в сборочной системе, в факте появления которого могли бы быть заинтересованы внешние сервисы. Возможно, этот же механизм стоит использовать и для внутренних компонент сборочницы. Вопрос, на который пока нет ответа: какую систему использовать в качетстве MQ (я знаю только про rabbitmq), насколько она надёжная/кластеризуемая. Какие интерфейсы/API должны быть к ней (какие пожелания) для внешних сервисов. Насколько публичным должен быть интерфейс API ?
Как происходит сейчас (по крайней мере в большинстве известных мне сервисов): или опрос по крону вплоть до ssh или отслеживание писем от girar Внутри сборочницы есть некий самописный MQ реализованный на файлах/каталогах.
Возможно, у такой службы есть ещё потенциальные клиенты в виде догоняющих репозиториев, которым задания нужно выгребать по факту их выполнения в основной сборочнице. Но так же было бы неплохо от догоняющих репозиториев получать информацию для сопутствующих служб, например для систем автоматизации функций отдела тестирования или webery. Т.е. - по факту у нас сейчас работает не одна сборочница а несколько параллельных, но при этом только с основной сборочницы задания и репозитории отслеживаются внешними (для сборочницы) службами. наверное, стоит сразу предусмотреть возможность появления нескольких параллельно действующих сборочных систем, у каждой из которых может быть свои номера и состав сборочных заданий.
(In reply to Anton Farygin from comment #1) > Как происходит сейчас (по крайней мере в большинстве известных мне сервисов): > или опрос по крону вплоть до ssh > или отслеживание писем от girar Для полноты картины упомяну, что робот, копирующий задания в mipsel-ную сборочницу по крону отслеживает $FROM_REPO/index/task.list.
Результат проверки актуальности Состояние: Реализовано: AMQP-события по заданиям, подзаданиям и ACL (girar-amqp-task/subtask/acl, girar-hook-event, 2022-04; события архиватора 2023-10). Рекомендация: закрыть (FIXED)
