OpenClaw를 CI에 넣을 때 핵심은 세 가지입니다: 누가 트리거하는가, 어디서 도는가, 어떻게 인증하는가. GitHub 호스팅 macOS 러너와 MacCloud의 셀프호스티드 러너를 함께 쓸 수 있습니다. 전자는 가벼운 단계, 후자는 디스크·커널 확장·상주 서비스에 민감한 부하에 적합합니다.
1. 트리거: 매 push에 전체를 돌리지 않기
긴 작업은 workflow_dispatch나 스케줄, PR에는 경로 필터로 불필요한 분을 줄입니다. OpenClaw 관련 단계는 별도 잡으로 분리해 일반 lint 매트릭스와 섞이지 않게 합니다.
2. 시크릿, 토큰, 감사
프로덕션 시크릿은 GitHub Environments에 두고 필수 리뷰어를 둡니다. MacCloud API나 티켓 API에는 단기 토큰을 순환하며 저장소에 하드코딩하지 마세요. 감사 로그로 「어떤 run이 어떤 자격 증명을 썼는지」를 추적할 수 있어야 합니다.
3. MacCloud의 셀프호스티드 러너
전용 Mac에 러너를 등록한 뒤 OpenClaw 잡 전용 라벨(예: runs-on: [self-hosted, macOS, openclaw])을 달고 일반 iOS 빌드 큐와 분리합니다. 유지보수·OS 업그레이드 전에 GitHub에서 러너를 비활성화해 반쯤 업그레이드된 머신이 잡을 가져가지 않게 합니다.
4. 캐시, 아티팩트, 로그
큰 의존성은 Actions Cache나 내부 아티팩트 저장소를 쓰고, 로그·리포트는 artifact로 올려 OpenClaw 쪽 이벤트와 대조합니다. 캐시 키에 락파일 해시를 넣어 오래된 의존성을 최신으로 착각하지 않게 합니다.
5. 실패 시 영향 범위 줄이기
OpenClaw 단계에 타임아웃과 재시도 상한을 두고, 인증 실패·쿼터 고갈 등 복구 불가 오류는 즉시 실패·라벨 처리합니다. 무한 재시도로 큐를 막지 말고 백오프는 자동화 시나리오와 맞춥니다.
6. 자가 점검
- 트리거가 기본 브랜치, PR, 수동을 모두 다루나요?
- Environment 보호가 검토되지 않은 fork PR을 막나요?
- 러너 라벨이 잡 매트릭스와 1:1로 맞나요?
- artifact 로그가 트리아지에 충분한가요?
상주 프로세스와 러너를 함께 쓰면 MacCloud 실무를 다시 읽어 디스크, 정상 종료, 과금 경계를 맞추세요.
