Несколько лет назад мы решили перенести большую часть нашего кода в монорепозиторий. Много защитники указали на его преимущества, которые включают лучшую координацию между проектами и более простое управление зависимостями.
Но осталась одна проблема: ни одна из доступных интеграций GitHub для Slack не работает с монорепозиториями.. Slack имеет решающее значение для повседневного общения между глобальной командой Ahref, поэтому интеграция со Slack была обязательной функцией. Нам нужен был сервис, который мог бы сопоставлять активность наших различных подпроектов с соответствующими каналами Slack — чего не предлагали существующие решения.
Вот почему мы построили собственную интеграцию: Моноробот, бот уведомлений для монорепозиториев. Мы неоднократно улучшали его с момента перехода на монорепозиторий, получая обратную связь от наших инженеров в режиме реального времени. Сегодня Monorobot является активным участником рабочего пространства Ahref Slack, добросовестно отправляя уведомления о действиях GitHub по разным каналам в зависимости от важности каждого действия.
И теперь мы моноробот с открытым исходным кодом, чтобы все могли использовать в настройке монорепозитория! Пакет доступен через СЕСТРЫ:
opam install monorobot
Читайте дальше, чтобы получить дополнительную информацию о поощрениях, обзор основных функций и то, что находится в разработке.
В монорепозитории код нескольких проектов находится в отдельных вложенных папках. Точно так же канал Slack каждого проекта интересует только активность из этой части общего репозитория. Проблема с большинством интеграций GitHub-to-Slack заключается в том, что когда вы подписываетесь на канал Slack в репозиторий GitHub, канал получает все активность из этого репозитория.
Допустим, мы запускаем различные службы, связанные с верблюдами, и планируем запустить новое приложение для катания на верблюдах под названием Camel Ride. Структура папок может выглядеть так:
monorepo/
| frontend/
| | camelride_ui/
| | | mobile/
| | | web/
| | cameldance/
| backend/
| | camelride/
| | | routing/
| | | pricing/
| | camelfood/
Как видите, оба frontend/ и backend/ папки содержат код для нашей службы псевдообмена вместе с кодом из других проектов.
Если бы мы связались GitHub для Slack интеграция с этим репозиторием, уведомления об активности всех проектов будут отправляться по одному и тому же каналу. Даже если бы меня интересовала только активность проекта Camel Ride, мне пришлось бы просеивать уведомления от других, не связанных проектов. Представьте себе количество уведомлений, которые это создаст для более крупного монорепозитория с десятками проектов. Какой беспорядок!
Monorobot позволяет более точно контролировать получение уведомлений из одного и того же репозитория в зависимости от типа активности. Это поведение маршрутизации может быть определено в файле конфигурации с именем .monorobot.json, который должен быть зафиксирован в корневом монорепозитории. Как только вы создали Веб-перехватчик GitHub из репозитория в работающий экземпляр Monorobot, он будет использовать файл конфигурации для маршрутизации уведомлений в соответствующие каналы на основе полезной нагрузки события веб-перехватчика:
- Для принудительных коммитов он проверяет префикс пути к файлам, измененным в коммитах.
- Для мероприятий, связанных с PR и вопросами, он проверяет их оценки.
- Для обновлений состояния принудительных коммитов (например, сборок CI) используется тот же префикс пути, что и для принудительных коммитов.
Кроме того, структура Monorobot поддерживает ссылки GitHub, которыми поделились в Slack.
Фиксированный префикс пути для push-уведомлений о коммите
Продолжая наш пример, предположим, что мы хотим направить всю активность фиксации, связанную с проектом Camel Ride, в канал Slack с именем #поездка на верблюде. Наш файл конфигурации может выглядеть так:
{
...,
"prefix_rules": {
"rules": [
{
"match": [
"frontend/camelride_ui/",
"backend/camelride/"
],
"ignore": [
"frontend/camelride_ui/images",
],
"channel": "camelride"
}
]
}
}
Каждое правило «соответствует» пути файла к каналу. Всякий раз, когда кто-то совершает фиксацию, касающуюся файлов с любым из этих префиксов, #поездка на верблюде канал будет уведомлен. Все остальные обязательства будут игнорироваться.
Если префикс файла появляется в необязательном правиле ignore поле, правило не будет соответствовать, даже если префикс также включен match поле. В приведенном выше фрагменте команда внешнего интерфейса Camel Ride решила отключить уведомления об активности в images/ подкаталог.
Теперь предположим, что команда по оптимизации цен проекта растет, и они решили создать свой собственный канал Slack под названием #верблюжьи цены. Мы можем просто выполнить обновление на .monorobot.json файл, и Monorobot обнаружит изменение конфигурации:
{
...,
"prefix_rules": {
"rules": [
{
"match": [
"frontend/camelride_ui/",
"backend/camelride/"
],
"ignore": [
"frontend/camelride_ui/images",
],
"channel": "camelride"
},
{
"match": [
"backend/camelride/pricing/"
],
"channel": "camelride-pricing"
}
]
}
}
Поскольку Monorobot будет соответствовать правилу с самым длинным совпадающим префиксом, будут уведомлены только коммиты, связанные с элементами оптимизации цены Camel Ride. #верблюжьи ценыи все другие общие обязательства Camel Ride будут уведомлены #поездка на верблюде.
Существуют дополнительные параметры конфигурации для правил префиксов (и для правил тегов, обсуждаемых в следующем разделе), которые здесь не упоминаются. Посещать хранилище для всей информации.
Бренд-ориентированный способ PR и публикации объявлений
Для действий, связанных с запросами на вытягивание и проблемами (открытие, закрытие, слияние, комментирование и просмотр), Monorobot использует сигналы для определения маршрутизации. Формат во многом такой же, как и для маршрута с префиксом маршрута:
{
...,
"label_rules": {
"default_channel": "notifications",
"rules": [
{
"match": [
"Camel Ride"
],
"channel": "camelride"
},
{
"match": [
"Price Optimization"
],
"channel": "camelride-pricing"
}
]
}
}
Здесь всем PR и проблемам с тегом «Поездка на верблюде» будет отправлена информация об активности. #поездка на верблюде; с пометкой “Оптимизация цен” #верблюжьи цены; и те, у которых оба сигнала на обоих каналах.
default_channel поле дает возможность вернуться к каналу, если ни одно правило не соответствует; этот параметр также доступен для префиксных правил.
Уведомления о статусе
Monorobot также поддерживает уведомления о состоянии сборки для конвейеров непрерывной интеграции. Когда он получает обновление статуса для принудительной фиксации, он направляет его на соответствующий канал (каналы), применяя правила префикса к фиксации, связанной со сборкой. Также возможна дальнейшая фильтрация на основе состояния (например, игнорировать отмененные сборки и сообщать только об успешных сборках, которым предшествуют сбои).
Ссылка удалена
Наконец, Monorobot может создавать ссылки на репозитории GitHub, размещенные в Slack (в том числе приватные, если предоставлен персональный ключ доступа). Это относится к URL-адресам фиксации, выпуска и запроса на извлечение.
Моноробот активно используется в Ahrefs сегодня, но у него есть много перспективных направлений в будущем. Здесь мы перечисляем некоторые.
Объединяет идентификаторы GitHub и Slack.
Было бы полезно разрешить сопоставление идентификаторов пользователей GitHub со Slack. Это позволит использовать больше настраиваемых функций для Monorobot, таких как отправка сообщений пользователю напрямую, когда запрашивается его обзор, или когда сборка CI дает сбой в написанной им тематической статье.
Объединение уведомлений
Иногда имеет смысл сгруппировать набор из нескольких событий веб-перехватчиков GitHub и доставить их в виде одного уведомления Slack. Например, проверки запросов на включение генерируют отдельные события webhook для каждой проверки проверки, но было бы разумнее объединить их, чтобы не засорять канал несколькими уведомлениями.
Улучшенные уведомления о статусе
Сбой сборки CI может иметь множество возможных причин:
- Плохое обязательство
- Предыдущее плохое обязательство, которое еще предстоит исправить
- Проблемы с самим пайплайном (это выходит за рамки Monorobot)
Отличить первые две причины только от события веб-перехватчика GitHub может быть довольно сложно. Причина 1 хорошо обрабатывается нашим текущим подходом к использованию пути префикса пути в фиксации, связанной со сборкой. Но с причиной 2 этот же подход не всегда отправляет уведомление об ошибке сборки в канал, где он фактически применяется. В этом случае автор первого плохого коммита не будет жаловаться на все последующие сбои, а каналы Slack, не имеющие отношения к причине сбоя, будут завалены избыточными уведомлениями.
Как мы можем лучше всего определить, является ли объявление статуса «актуальным» для канала Slack? Это все еще открытый вопрос, но одной из возможных стратегий является отслеживание состояния строительства в каждом конкретном случае. построить шаги а не за позицияи маршрутизировать уведомления на его основе. Например, если полная сборка завершается со сбоем из-за сбоя на этапах сборки серверной части, она может быть отправлена в канал, по которому команда внешнего интерфейса не будет уведомлена.
Общая цель Monorobot — сделать уведомления Slack более распространенными. соответствующий для всех команд в целом среда монорепозитория, используя информацию, доступную из событий веб-перехватчика GitHub. У нас были довольно положительные результаты с нашим собственным внутренним использованием, и теперь мы надеемся, что другие тоже найдут его полезным.
Моноробот написан на OCaml. Мы приветствуем ваши комментарии и комментарии на GitHub!
PS Если кто-то делает настоящий сервис по обмену верблюдов, дайте нам знать…
