Контекст: Workflows и миграция webhook
Microsoft постепенно отключает создание классических коннекторов и переводит сценарии на потоки в приложении Workflows в Teams. Практический шаблон — «отправить оповещение по webhook в канал»: вы выбираете команду и канал, получаете новый HTTPS URL, который в большинстве случаев можно подставить вместо старого как drop-in, если тело запроса остаётся в поддерживаемом формате (в т.ч. MessageCard). Учтите организационные нюансы: поток может быть привязан к владельцу, поэтому зафиксируйте ответственного и процедуру передачи при увольнении. Официальная документация Microsoft Learn по добавлению webhook и разделу «Connectors» — ориентир по поддерживаемым сценариям на 2026 год.
Для MeshMac это не меняет архитектурный принцип: Mac-узлы не ходят в Teams напрямую, они только публикуют события во внутреннюю шину, а один шлюз держит секрет и лимиты исходящих вызовов.
Шаг 1–2: привязка канала и авторизация
Шаг 1. В канале Teams откройте меню канала → Workflows (или эквивалент в вашем клиенте), найдите шаблон вроде Send webhook alerts to a channel, подтвердите имя команды и канала. Сохраните поток — вы получите URL для входящих HTTP POST.
Шаг 2. Проверьте политику тенанта: кто может создавать потоки, нужен ли отдельный согласующий. Для production и staging используйте разные каналы и разные URL, чтобы тестовый сценарий не писал в канал релизов. Если канал общий или shared channel, убедитесь, что шаблон Workflows это поддерживает в вашей версии клиента (политика Microsoft обновлялась поэтапно в 2025–2026).
Шаг 3–4: установка шлюза и хранение URL
Шаг 3. Разверните или выделите хост шлюза OpenClaw по той же схеме, что в руководстве по мультиузлу (см. ссылку в лиде): отдельная ВМ или bastion, стабильный egress, LaunchDaemon/systemd с предсказуемым окружением. Выполните onboard, doctor и проверку здоровья.
Шаг 4. Сохраните webhook URL в файле вроде /etc/openclaw/secrets.d/teams/workflows-build.url с правами 0440, владелец root, группа роли вроде openclaw-notify. Не копируйте файл на builder-узлы: они передают только нормализованные поля (mesh_node_id, provider_run_id, состояние, ссылки на логи) в очередь шлюза.
Исходящий трафик: согласуйте с ИБ allowlist к хостам Microsoft (часто *.webhook.office.com и связанные имена вашего региона) и проверьте curl -I с хоста шлюза с теми же переменными прокси, что у демона.
Шаг 5–6: потоковая сводка и финальный broadcast
Шаг 5 (потоковая сводка). Когда одна логическая сборка размазана по нескольким Mac, удобно показывать прогресс: по мере завершения job на узле шлюз отправляет короткое сообщение с префиксом вроде «[узел 2/3]» и тем же correlation_id, либо обновляет внутреннее состояние без лишнего шума в канале — выбор за политикой команды. Важно ограничить частоту POST, чтобы не упереться в throttling со стороны Microsoft.
Шаг 6 (финальный broadcast). Когда собраны статусы всех узлов для provider_run_id, шлюз формирует одну карточку: общий итог (успех / первый сбой / отмена), таблица по узлам, ссылки на CI. Дедупликация: ключ provider_run_id + state в окне (например 72 часа), согласованно с политикой очереди (см. лид). Так канал остаётся читаемым и не дублирует финал при сетевых ретраях.
Ротация URL и политика повторов
Ротация: создайте новый поток Workflows или перевыпустите URL, обновите файл секрета на шлюзе, выполните перезапуск сервиса, затем удалите старый поток после окна наблюдения. Зафиксируйте runbook смены URL в той же дисциплине, что и ротация прочих исходящих токенов.
Повторы: на 429 и 5xx — экспоненциальный backoff с джиттером и потолком попыток; на 400/401 — не зацикливаться, а чинить JSON или URL. При 404 трактуйте как потерю endpoint и эскалируйте владельцам Teams.
Типовые ошибки и диагностика
| Симптом | Вероятная причина | Действие |
|---|---|---|
| HTTP 400, пустой канал | Неподдерживаемая схема JSON или устаревший payload после миграции | Сверить с актуальным примером MessageCard; упростить тело до минимально валидного |
| HTTP 401/403 | Отозванный или неверный URL, смена потока | Пересоздать webhook в Workflows, обновить секрет, проверить с того же хоста что шлюз |
| Только часть узлов «видит» сбой | Прямой вызов Teams с обходом шлюза или старый egress | Убрать per-node webhook; единый путь через шлюз |
| Дубликаты финальных карточек | Повторы без идемпотентности | Включить дедуп по provider_run_id+state; один финальный POST на логический run |
При переключении узлов пула не переносите webhook на builder: секрет остаётся на шлюзе, очередь — единая точка согласования.
Краткий FAQ
Нужен ли отдельный webhook на каждый Mac? Нет — это ломает минимальные права и усложняет ротацию. Держите один URL на шлюзе.
Можно ли обойтись без «потоковых» промежуточных сообщений? Да: только финальный агрегат по всем узлам — проще и тише для канала.
Где смотреть первичную статью про Teams webhook? В базовом HowTo по Teams (ссылка в лиде) — там поля CI и egress без акцента на Workflows.
Дальше без входа в аккаунт
Главная, каталог блога, справочный центр и страница оформления аренды доступны сразу — без регистрации для просмотра цен и чеклистов.
Свяжите Workflows с пулом MeshMac — один шлюз, предсказуемые уведомления
Откройте главную Meshmac, чтобы спланировать ёмкость под несколько CI-узлов; загляните в блог и в справку перед оформлением. Покупка и расширение сценария удобнее, когда шлюз и Teams уже согласованы по этому HowTo.