---
tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
---

# 24 자동배포 0초 종료와 runtime SSOT 불일치 이슈

## 관련 문서
- [24서버 robeing runtime workspace-config 단일화](../worklog/260310_24서버_robeing_runtime_workspace_config_단일화.md)
- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](./260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
- [23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](./260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)

## 문제
- `rb8001` 최신 커밋 푸시 후 Gitea Actions `cicd.yml`이 `0s`로 종료되고 자동 배포가 실제로 수행되지 않았다.
- 같은 시점에 24 실행 서버 `rb8001` 컨테이너는 재시작되지 않았고, 수동 `docker compose down && docker compose up -d --build` 후에만 코드가 반영됐다.

## 확인된 사실
- 현재 24 실행 서버의 runtime SSOT는 `192.168.0.106`이다.
- 과거 24 주소 `192.168.219.52`는 런타임과 영구 설정 모두에서 제거돼야 하는 대상으로 이미 정리돼 있다.
- 24 실행면의 공용 런타임 값은 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`가 SSOT다.
- 기존 인프라 문서상 배포 실패의 대표 원인은 `DEPLOY_PROJECT_DIR` 같은 단일 기준을 안 쓰고 서비스별 하드코딩 경로/값을 남긴 경우였다.
- 이번 건은 자동 배포가 실행되지 않았지만, 같은 서버에서 수동 배포는 정상 성공했다.
- `rb8001/.gitea/workflows/cicd.yml`은 `secrets.*`나 `vars.*`가 아니라 저장소 루트 `.env.deploy`를 직접 읽도록 작성돼 있다.
- 현재 `rb8001` 저장소에는 `.env.deploy`가 없고 `.env.deploy.example`만 존재한다.
- `rb8001/.env.deploy.example`에는 아직 `DEPLOY_SSH_HOST=192.168.219.45`, `DEPLOY_SSH_PORT=51123`가 남아 있다.
- 반면 `skill_email`, `robeing-monitor`, `skill-rag-file`의 실제 `.env.deploy`는 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`로 맞춰져 있다.
- Gitea API 기준 `rb8001` 저장소의 Actions secrets/variables 목록은 현재 빈 배열(`[]`)이다.

## 현재 해석
- 애플리케이션 코드 자체 문제보다는 `Gitea Actions -> 24 배포 경로`의 SSOT 불일치 가능성이 높다.
- 특히 `rb8001`은 다른 서비스와 달리 `.env.deploy` 실파일이 없고, 예시 파일도 구주소를 가리켜 자동 배포 경로가 SSOT에 수렴하지 않은 상태다.

## 직접 영향
- `git push origin main`이 배포 완료를 의미하지 않게 된다.
- 운영자가 수동 배포로 개입해야 하므로 배포 재현성과 추적성이 깨진다.

## 한 줄 결론
- 이번 자동 배포 실패는 `24 실행면 runtime SSOT`와 `Gitea Actions 배포 경로`가 다시 어긋났을 가능성이 높은 상태다.