2026 OpenClaw MeshMac на практике: минимально воспроизводимые шаги для входящего webhook Google Chat и трансляции статуса сборки с нескольких узлов

Следуйте топологии «сначала шлюз» из руководства по мультиузловому развёртыванию MeshMac: один хост (небольшая ВМ, bastion или выделенный Mac) запускает сервисы OpenClaw, выполняет исходящие POST к SaaS и читает секреты из изолированного каталога. Сборщики на пуле не хранят полный URL Chat: они публикуют нормализованное событие «сборка завершена» во внутреннюю шину или очередь, как в материале про единый деплой и синхронизацию очереди.

Задайте OPENCLAW_CONFIG_ROOT, завершите onboard, прогоните проверки здоровья и убедитесь, что демон стартует с тем же окружением, что ожидает CI. URL webhook сохраните в файл вроде /etc/openclaw/secrets.d/google-chat/build-status.url с правами 0440, владелец root, группа узкой роли вроде openclaw-notify — так процесс уведомлений читает секрет, а остальные пользователи узла — нет.

Контрольная точка A — права на файл.

sudo install -d -m 0750 -o root -g openclaw-notify /etc/openclaw/secrets.d/google-chat
sudo sh -c 'umask 077; cat > /etc/openclaw/secrets.d/google-chat/build-status.url' <<'EOF'
https://chat.googleapis.com/v1/spaces/SPACE/messages?key=KEY&token=TOKEN
EOF
sudo chown root:openclaw-notify /etc/openclaw/secrets.d/google-chat/build-status.url
sudo chmod 0440 /etc/openclaw/secrets.d/google-chat/build-status.url

Замените placeholder на URL, который выдаёт мастер создания webhook в Chat. Мультиплатформенное замечание: для Teams и Matrix шлюз остаётся тем же, меняется только путь к файлу секрета и целевой хост — единая модель упрощает runbook и учения по инцидентам.

В целевом пространстве Google Chat добавьте интеграцию Incoming Webhook (дайте понятное имя — репозиторий или имя пула), выберите пространство и один раз скопируйте сгенерированный HTTPS URL. В строке присутствуют параметры key и token — по сути это bearer-учётные данные: любой, кто знает полный URL, может писать в пространство. При утечке webhook отзовите и создайте заново; частичной ротации обычно нет.

• Разные пространства для сред, чтобы staging не присылал «успех» в рабочее пространство руководства.
• Исходящий трафик: с оболочки шлюза проверьте TLS к chat.googleapis.com с теми же HTTPS_PROXY, что у демона.
• Политика Workspace: если произвольные webhook запрещены, используйте одобренное Chat-приложение или контролируемый HTTP endpoint (например Apps Script) — по-прежнему один логический отправитель со стороны MeshMac.

Контрольная точка B — доступность.

export HTTPS_PROXY="${HTTPS_PROXY:-}"
curl -sS -o /dev/null -w "%{http_code}\n" -I "https://chat.googleapis.com/"

Ожидайте ответ под контролем Google (часто 404 на «голый» GET), но не ошибки TLS или запрет прокси 403. Сеть нужно стабилизировать до отладки JSON.

Минимальный надёжный формат для служебных сообщений — UTF-8 JSON с полем text. Карточки и интерактивные виджеты можно добавить после того, как простой текст стабильно доходит до пространства.

export CHAT_URL="$(sudo cat /etc/openclaw/secrets.d/google-chat/build-status.url)"
curl -sS -X POST "$CHAT_URL" \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -d '{"text":"MeshMac: проверка шлюза OK с '"$(hostname -s)"'"}'

Контрольная точка C — сообщение видно. Строка должна появиться в пространстве в течение нескольких секунд. Если API вернул JSON с ошибкой, разберите тело ответа до автоматизации.

Для продакшена соберите одну строку: метка state (эмодзи или текст по договорённости команды), ветка, короткий хеш коммита, ссылка на прогон провайдера и mesh_node_id. Длинные логи не вставляйте — дайте run_url. Для Teams подставьте карточку коннектора и разрешите *.webhook.office.com на периметре; для Matrix — сообщение в комнату через homeserver: очередь и таблица полей на шлюзе остаются общими.

Предположим, три builder’а MeshMac завершают job почти одновременно. Каждый публикует нормализованную запись в Redis, NATS или ткань задач OpenClaw. Потребитель на шлюзе приводит payload провайдера к единой схеме и только затем рендерит text для одного POST в Chat:

✅ ios-release · main · abc1234 · <https://github.com/org/repo/actions/runs/18451203> · узел mm-pool-2

Если два узла сообщают одинаковые provider_run_id и state, шлюз должен дедуплицировать в выбранном окне (часто 24–72 часа), иначе ретраи сети раздуют поток. Политику повторов внутренней очереди согласуйте с шагами очереди и повторов OpenClaw — это отдельно от кнопки «перезапустить сборку» в CI.

Считать ли webhook URL OAuth-токеном?

Нет. Это секрет конечной точки без scope OAuth. Защищайте ACL, не коммитьте в Git, в логах оставляйте хост и последние символы token.

Какие коды HTTP повторять?

429 и 5xx — экспоненциальная задержка, джиттер, небольшой потолок попыток (например пять за две минуты). 400 и 401 не ретраить: исправьте JSON или перевыпустите webhook. Повторяющийся 404 трактуйте как удалённый webhook.

Как не дублировать сообщения в Chat?

Храните успешные доставки по ключу provider_run_id + state в SQLite, Redis или локальном кэше шлюза; при попадании в окно дедупликации второй POST не выполняйте.

Можно ли вызывать Chat с каждого Mac «временно»?

Это множит секреты и правила egress. Один процесс на шлюзе упрощает ротацию, аудит и отработку отказа.

Главная, блог, справочный центр и страница тарифов и оформления аренды доступны сразу — регистрация для просмотра не требуется. Удобно согласовать ёмкость пула и чеклисты с командой до покупки.