Factory Automations запускает сессию Droid по расписанию, из сообщения верхнего уровня в Slack, по событию GitHub или на входящий HTTP-запрос. Триггеры вебхуков пока находятся в режиме Private Preview, а расписания используют фиксированное время UTC и сами не подстраиваются под переход на летнее время. Поэтому инструмент уже подходит для ограниченного пилота, но ещё не для безоговорочного внедрения в production.
Что именно запускает Factory Automations
Каждая автоматизация объединяет триггер, инструкции, учётную запись и целевую среду выполнения (документация Factory).
| Триггер | Что запускает выполнение | Главная особенность |
|---|---|---|
| По расписанию | Описание периодичности обычным языком или пятизначное cron-выражение | Запускается на выбранном компьютере или в целевой среде выполнения; управляемые компьютеры поддерживают 10 автоматизаций, из которых 5 могут запускаться раз в минуту |
| Slack | Подходящее сообщение верхнего уровня в канале | Ответ публикуется в исходной ветке |
| GitHub | Pull request, комментарий, push, метка, проверка или расписание | После завершения настройки запускается через GitHub Actions |
| Webhook | HTTP POST от другого сервиса | Droid Computer или шаблон выполнения; Private Preview |
Автоматизацию можно сделать приватной или доступной всей организации. При этом приватность сессии настраивается отдельно и определяет, кто сможет открывать сессии, созданные её запусками.
От триггера зависит вся модель эксплуатации
Запуски по расписанию — лучший способ начать
Расписание можно задать обычной фразой вроде «каждый понедельник в 9:00 PST» или через cron, например 0 9 * * 1. Factory показывает, к какому времени это приведёт, но cron работает в UTC. Указанный часовой пояс преобразуется в фиксированное расписание UTC, которое не меняется автоматически при переходе на летнее время (документация Factory).
Для первых экспериментов хорошо подходят ежедневная сводка статуса, проверка зависимостей, поиск устаревшей документации или ревьюер pull request, который собирает факты и рекомендации, но не сливает код.
Сообщения в Slack удобны, если нужны только сигналы верхнего уровня
Автоматизация Slack запускается, когда в доступном канале появляется подходящее сообщение верхнего уровня. Ответы внутри ветки сами по себе новый запуск не инициируют. Фильтры позволяют ограничить срабатывания шаблоном канала, типом отправителя, ключевыми словами, исключёнными словами или списком исключённых отправителей.
Результат публикуется в ветке исходного сообщения. Если подходят сразу несколько автоматизаций, только первая отвечает в этой ветке, а остальные отправляют отдельные сообщения со ссылкой на оригинал. Factory отдельно описывает эти правила и доступ к приватным каналам (документация Factory). Для контролируемого канала инцидентов это рабочий вариант, но он не подойдёт процессам, где важно реагировать на каждый последующий ответ в ветке.
События GitHub мощные, но требуют явного этапа настройки
Пользовательские автоматизации GitHub могут реагировать на pull request, push, комментарии, изменения меток, завершённые проверки или расписание. Они выполняются в GitHub Actions, а при создании автоматизации в каждом выбранном репозитории открывается setup pull request.
Пока этот setup pull request не будет влит, workflow не активируется. Запуски, начатые до появления workflow в ветке по умолчанию, завершаются ошибкой; до этого момента автоматизация также не может публиковать комментарии, отправлять коммиты или открывать pull request. GitHub — самый сильный вариант, если регулярная задача уже привязана к событию в репозитории, а обычное ревью pull request остаётся границей перед публикацией изменений.
Вебхуки: возможность есть, но доступ ограничен
Factory описывает автоматизации на вебхуках как функцию в режиме Private Preview и предлагает организациям обращаться в поддержку для её включения. Вебхук запускает выполнение по внешнему HTTP POST, но не работает на локальном компьютере пользователя: требуется Droid Computer или шаблон выполнения.
Factory выдаёт URL вебхука, поддерживает заголовок X-Webhook-Secret и предлагает форму URL для отправителей, которые не умеют задавать заголовки. В документации рекомендуется использовать именно заголовок, поскольку секрет в URL может попасть в логи. Секрет показывается один раз, а его ротация делает старое значение недействительным (документация Factory по вебхукам).
Та же документация устанавливает лимит тела запроса в 200 KiB, принимает не более 60 запросов в минуту, хранит записи о доставке 30 дней, дедуплицирует одинаковое тело в течение 10 минут и ограничивает число запусков 10 в час. Для тестирования реакции на уведомления этого достаточно, но статус Private Preview остаётся блокирующим фактором, если доступность механизма должна быть предсказуемой.
Какие настройки определяют безопасность автоматизации
Автоматизации по расписанию, из Slack и через вебхуки могут выполняться от имени пользователя или общей сервисной учётной записи. От выбранной идентичности зависят доступ к коннекторам, тарификация и отображение отправителя в Slack; правила для целевой среды перечислены в документации Factory.
Делайте промпт узким, используйте отзываемые учётные данные, выбирайте отдельную среду выполнения, а право на деплой и merge оставляйте за существующими механизмами контроля репозитория. В карточке Factory в Slack Marketplace прямо сказано, что приложение может ошибаться, поэтому код и ответы нужно перепроверять.
Один из пользователей отдельно отметил пробелы в надзоре — отсутствие приложения для Linux и синхронизации между компьютерами (пост @JoelDeTeves в X). Это важно учитывать, если команда рассчитывает контролировать длительные автоматизированные задачи не только за рабочим столом.
Factory Automations или обычный GitHub Action
| Задача | Factory Automations | Обычный GitHub Action |
|---|---|---|
| Запустить промпт для репозитория | Нативная сессия Droid и целевая среда выполнения | Команда самостоятельно предоставляет среду агента и код workflow |
| Запланированная задача | Обычный язык или cron с оговоркой про UTC | GitHub cron и собственная логика |
| Триггер Slack | Сообщения верхнего уровня, фильтры и ответы в ветке | Интеграция Slack или вебхук |
| Событие GitHub | Пошаговая настройка через setup PR и выполнение в GitHub Actions | Прямой workflow-файл |
| Webhook | Встроенный, но в режиме Private Preview | Нужно самостоятельно сделать endpoint, аутентификацию, повторы и worker |
| Граница ревью | Может подготовить результат для проверки человеком | Зависит от разрешений workflow |
GitHub Action стоит выбрать, когда задача сводится к детерминированной работе с API — например, к ежедневной сводке по pull request. Factory полезнее, если регулярный этап требует расследования, контекста репозитория, подготовки изменения кода или понятной человеку сессии. Не стоит выбирать агентскую платформу только ради того, чтобы не написать короткий скрипт.
Безопасный пилот, после которого автоматизации можно доверить больше
- Выберите одну регулярную задачу с ограниченным входом — например, ревью новых pull request или проверку сгенерированных файлов.
- Начните с автоматизации по расписанию, а не с вебхука: так не понадобится доступ к preview-функции, а периодичность будет проще контролировать.
- Пусть результатом станет отчёт или pull request, а не деплой или merge.
- Фиксируйте неудачные запуски, заблокированные задачи, изменённые файлы и исправления, внесённые людьми: одних принятых pull request недостаточно.
- Расширяйте пилот только по одному направлению за раз: новый класс задач, репозиторий или триггер.
В рекомендациях Factory по рабочим процессам предлагается воспроизводить исходную ошибку, проверять исправление в чистом окружении и тестировать соседний случай, прежде чем сохранять универсальную инструкцию. Для пилота Automation это разумный стандарт.
FAQ
Поддерживает ли Factory Automations вебхуки?
Да, но триггеры вебхуков находятся в режиме Private Preview и могут требовать включения на уровне организации. Для запуска нужен Droid Computer или шаблон выполнения. Подробности — в разделе о вебхуках выше.
Запускают ли ответы в ветке Slack новую автоматизацию?
Нет. Запуск происходит только по подходящему сообщению верхнего уровня; подробности — в разделе «Сообщения в Slack».
Подстраивается ли расписание под переход на летнее время?
Нет. Factory сохраняет фиксированное расписание UTC, поэтому при изменении местных правил перехода на летнее время его нужно проверять. См. раздел «Запуски по расписанию».
Запускаются ли автоматизации GitHub до merge setup pull request?
Нет. Сначала setup pull request должен попасть в ветку по умолчанию; более ранние запуски завершаются ошибкой. См. раздел «События GitHub».
Что происходит при повторной доставке вебхука?
Идентичное тело запроса, полученное в течение 10 минут, получает статус Deduped, и новый запуск не создаётся. Factory также фиксирует отфильтрованные, ограниченные по частоте, пропущенные и неудачные доставки.
Главный компромисс, о котором нельзя забывать
Пилотируйте задачи по расписанию или через GitHub, если результат можно оставить внутри цикла проверки pull request. Slack хорошо работает при договорённости использовать сообщения верхнего уровня. Вебхуки достаточно подробно проработаны для тестирования, но статус Private Preview пока не позволяет строить на них production-систему реагирования на инциденты.