Встраивая OpenClaw в CI, ответьте на три вопроса: кто запускает, где выполняется, как проходит аутентификация. Раннеры macOS на GitHub и self-hosted на MacCloud сочетаются: первые для лёгких шагов, вторые, когда важны диск, kext’ы или постоянные сервисы.
1. Триггеры: не гонять полный пайплайн на каждый push
Длинные задачи — workflow_dispatch или расписание; для PR — фильтры путей. Шаги OpenClaw выносите в отдельный job, чтобы их не рвало в общей lint-матрице.
2. Секреты, токены, аудит
Прод-секреты в GitHub Environments с обязательными ревьюерами. Для API MacCloud или тикетов — краткоживущие токены с ротацией, без хардкода в репозитории. Аудит должен отвечать, «какой run использовал какие учётные данные».
3. Self-hosted runner на MacCloud
После регистрации на выделенном Mac пометьте задачи OpenClaw отдельными метками (например runs-on: [self-hosted, macOS, openclaw]) и изолируйте от общих iOS-очередей. Перед обслуживанием или обновлением ОС отключайте раннер в GitHub, чтобы наполовину обновлённая машина не брала работу.
4. Кэш, артефакты, логи
Крупные зависимости — через Actions Cache или внутренний реестр; логи и отчёты загружайте артефактами для сопоставления с событиями OpenClaw. Ключи кэша включают хэш lock-файлов.
5. Сужение зоны поражения при сбое
Таймауты и лимиты повторов для шагов OpenClaw; при ошибках аутентификации или исчерпании квоты — быстрый fail и метка, а не бесконечные ретраи. Бэкофф согласуйте с сценариями автоматизации.
6. Чек-лист
- Триггеры покрывают основную ветку, PR, ручной запуск?
- Защита окружений блокирует неревьюнутые fork PR?
- Метки раннеров один к одному с матрицей job?
- В артефактах логи достаточной глубины?
При совместной работе постоянных процессов и раннеров перечитайте практику на MacCloud: диск, корректное завершение, границы биллинга.
