2026 OpenClaw MeshMac на практике: мультиузел, monorepo path filter, инкрементальные сборки и краткая сводка в Slack — минимально воспроизводимые шаги

Начните с устойчивой опоры для diff: в GitHub Actions достаточно dorny/paths-filter или короткого скрипта с git diff --name-only "$BASE_SHA"...HEAD. Каждый изменённый файл сопоставьте с корнем пакета — например apps/ios/** → apps/ios, packages/core/** → packages/core. Храните таблицу соответствий в YAML рядом с репозиторием, чтобы ревьюеры ловили ложные отрицания до продакшена.

На выходе фиксируйте один артефакт для остального конвейера: JSON-массив вроде ["apps/ios","packages/core"] или построчный список. Если фильтр не зацепил критичное, запускайте дешёвый smoke, а не полную матрицу. Turbo, Nx или Bazel заменяют ручные глобы командами affected, но контракт тот же: downstream на всех узлах MeshMac читает один нормализованный план «что собирать».

На main и релизных ветках ужесточите правило: изменения в ci/** или .github/** расширяют план хотя бы на один «полный» проход мобильных целей, после чего снова включается инкремент. Параллельные worktree и гонки за lockfile на одной машине регулируйте отдельно — сверьтесь с матрицей Git worktree и lockfile, чтобы path filter не спорил с Package.resolved.

Инкремент экономит CPU, но не снимает конкуренцию за подпись, симуляторы и глобальные кеши. Выберите один паттерн и опишите его в runbook:

• Центральная очередь — воркеры забирают задачи из Redis, RabbitMQ или ткани задач OpenClaw, как в материале про единый деплой и синхронизацию очереди; для дорожек с Xcode ограничьте число consumer до одного.
• Кооперативный flock — на общем томе держите, например, /build-locks/ios.signing.lock; обёртка с flock и таймаутом. Про застрявшие блокировки — FAQ по очереди и flock.

Область блокировки согласуйте с лимитами шлюза и параллельными сессиями, иначе CI откроет двадцать сессий при одном слоте подписи.

Сырые логи CI плохо читаются в чате. После шага сборки поставьте локальную для шлюза задачу OpenClaw (или детерминированный шаблон), которая потребляет структуру: код выхода, список собранных пакетов, mesh_node_id, wall time и первую ошибку компилятора или теста. Текст — до четырёхсот слов, в начале — «Собранные пакеты: …», в конце — ссылка на прогон провайдера.

JSON плана path filter передайте в контекст задачи, чтобы не угадывать пакеты из лога. Если экспортируете xcresult, укажите OpenClaw на срез plist/JSON со списком упавших тестов, а не на полный транскрипт xcodebuild. На зелёных прогонах можно использовать статический шаблон (Handlebars и аналоги) — предсказуемая задержка, когда пять узлов завершают работу в одну минуту.

Секреты в сводку не включайте: только credential_id или имя job. Общую схему полей и дедупликации согласуйте с шаблоном webhook для общей сборки, чтобы позже Teams или Matrix получили тот же каркас.

Классический Incoming Webhook Slack — один HTTPS URL на канал. Это удобно и опасно: зная URL, можно заспамить канал. Относитесь как к bearer-секрету: файл 0440, владелец root или пользователь шлюза, группа узкой роли вроде openclaw, никогда в Git. Только процесс на шлюзе читает файл и выполняет POST; runner’ы шлют события во внутреннюю очередь шлюза.

Исходящий трафик: разрешите hooks.slack.com (и корпоративный прокси по SNI). Проверка с шлюза до автоматизации:

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

Раскладку секретов и минимальные права на узлах выровняйте с гайдом по секретам и минимальным правам на узлах MeshMac. Когда webhook’ов станет мало, мигрируйте на Slack-приложение с bot token, но сохраните дисциплину одного отправителя.

Slack периодически отвечает 429 или транзиентными 5xx. Повторяйте с exponential backoff, полным джиттером и жёстким потолком — разумный старт: пять попыток за две минуты. Практичный sleep: random_between(0, min(cap_ms, base * 2**attempt)), чтобы синхронные runner’ы не били в одну секунду. Уважайте заголовок Retry-After, если он есть.

400 и 404 не ретраить: исправьте JSON или перевыпустите webhook. Дедуплицируйте по provider_run_id + conclusion хотя бы 72 часа, чтобы повторные прогоны CI не дублировали сообщения. Семантику повторов самой очереди смотрите в шагах очереди и повторов OpenClaw.

Если шлюз за балансировщиком, согласуйте дренаж и health check с шагами балансировки и failover, иначе половина доставок в Slack оборвётся на выводимом узле.

Можно ли убрать блокировку, если сборка уже инкрементальная?

Инкремент не снимает конкуренцию за подпись, симуляторы и глобальные кеши. Узкую блокировку вокруг этих фаз оставьте даже при точном path filter.

Нужен ли LLM на каждый зелёный прогон?

Нет. Шаблон для успеха (эмодзи, длительность, пакеты), вызов модели — для падений или двусмысленных ошибок парсера.

Устарел ли Incoming Webhook?

Slack поощряет приложения в новых workspace, но webhook остаётся рабочим для внутреннего CI. Заложите путь миграции, не блокируя минимальный контур из этой статьи.

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