develop 병합 PR 연결 Issue 자동 종료 자동화

[exijn]

✨ 작업 내용

develop에 병합된 PR 본문의 공식 closing keyword를 해석해 같은 저장소의 연결 Issue를 자동으로 종료하는 GitHub Actions를 추가했습니다. 기본 브랜치 main과 기존 Git Flow 및 CI는 유지합니다.

---

🔍 리뷰 시 참고사항

배경과 정책

• GitHub 기본 closing keyword는 기본 브랜치 대상 PR에서 동작하므로, feature/* → develop PR의 Issue가 병합 후에도 남는 문제를 해결합니다.
• Workflow는 pull_request의 closed 이벤트에서 실제 병합 여부를 확인하고, base가 정확히 develop인 경우에만 처리합니다.
• main은 운영·배포 안정 브랜치이자 GitHub 기본 브랜치로 유지합니다. develop → main 릴리스 PR은 이 자동화의 대상이 아닙니다.
• Workflow가 기본 브랜치에 존재해야 하므로 이 PR은 최신 main에서 생성했으며, 이 PR이 main에 병합된 이후부터 자동화가 활성화됩니다.

지원 범위

• close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved를 대소문자 구분 없이 지원합니다.
• Closes #32, CLOSES: #32, Resolves: #34 형식과 각 Issue에 keyword를 반복한 다중 참조를 지원합니다.
• PR 본문만 분석하며 PR 제목·브랜치 이름·커밋 메시지의 Issue 번호는 사용하지 않습니다.
• Refs, Related, 단순 #N, 코드 블록·인라인 코드·HTML 주석·URL·다른 저장소 참조·존재하지 않는 Issue·Pull Request 번호·비공식 Closes #1, #2 축약형은 처리하지 않습니다.
• GitHub API로 같은 저장소의 Issue 존재 여부·Pull Request 여부·현재 open 상태를 확인한 뒤 completed 사유로 닫습니다.

멱등성 및 실패 처리

• PR 번호 marker(auto-close-develop-pr:<number>)가 있는 감사 Comment는 다시 작성하지 않습니다.
• 동일 PR의 여러 keyword가 같은 Issue를 가리켜도 한 번만 처리합니다.
• 이미 닫힌 Issue와 잘못된/존재하지 않는 참조는 Skip합니다.
• Comment 작성 후 Issue 종료가 실패해도 재실행 시 marker를 이용해 중복 Comment 없이 종료를 재시도합니다.
• 개별 API 실패는 다른 Issue 처리를 계속하고, 실패한 Issue 번호와 사유를 Job Summary에 남긴 뒤 Workflow를 실패 처리합니다.

보안

• Workflow와 Job 권한은 contents: read, pull-requests: read, issues: write만 부여합니다.
• GITHUB_TOKEN만 사용하며 PAT·추가 Secret·pull_request_target을 사용하지 않습니다.
• PR Head 코드는 Checkout하거나 실행하지 않고, main을 명시적으로 Checkout해 신뢰된 자동화 모듈만 실행합니다.
• 외부 Fork PR은 GITHUB_TOKEN Issue 쓰기 제한을 우회하지 않도록 자동 종료 대상에서 제외합니다.
• PR 본문은 Shell 명령에 보간하지 않으며 eval이나 전체 Event Payload 로그를 사용하지 않습니다.

변경 파일과 문서

• .github/workflows/close-develop-issues.yml
• .github/scripts/close-develop-issues.js
• .github/scripts/close-develop-issues.test.js
• .github/PULL_REQUEST_TEMPLATE.md: Closes #이슈번호 예시로 보완
• docs/GIT_FLOW.md: 브랜치 전략, Issue 연결 규칙, 자동화 조건과 동기화 절차 문서화

소급 정리

• Issue 결정 필요: 캡슐 암호화 모델 — 설계 문서(E2E)와 현재 구현(서버 봉투 암호화) 불일치 #32: PR #33이 develop에 병합되고 본문에 Close #32가 있어 감사 Comment를 남긴 뒤 completed 사유로 종료했습니다.
• Issue Docker 기반 운영 배포 환경 구성 #34: PR #35가 develop에 병합되고 본문에 Close #34가 있으며, 이미 completed 사유로 닫힌 상태임을 확인했습니다.
• 현재 열린 Issue를 재감사한 결과 신규 자동화 Issue #36만 열려 있으며, 이 PR이 main에 병합될 때 닫히도록 아래에 Closes #36을 명시했습니다.

테스트 및 검증

• Node.js 파서·Mock GitHub API 테스트 6개 통과
• 공식 keyword·대소문자·콜론·다중 참조·중복 참조 검증
• 미병합 PR·다른 base·다른 저장소·Fork PR Skip 검증
• 코드 블록·인라인 코드·HTML 주석·URL·비공식 참조 제외 검증
• 이미 닫힌 Issue·Pull Request·없는 Issue Skip 검증
• 감사 Comment 중복 방지와 개별 API 실패 후 계속 처리 검증
• JavaScript 문법 검사 및 Workflow YAML 파싱 통과
• git diff --check 통과
• ./gradlew test 전체 통과

./gradlew test는 JDK 23 격리 환경에서 컴파일·테스트 클래스 생성까지 통과했으나, 기존 MuddaApplicationTests가 Testcontainers의 Docker 데몬을 찾지 못해 1개 실패했습니다. 로컬 Docker 데몬 부재에 따른 환경 제한이며 변경한 파서 테스트는 모두 통과했습니다. actionlint는 환경에 설치되어 있지 않아 공식 YAML 구조와 로컬 YAML 파서로 검증했습니다.

자체 코드 리뷰

• 1차 리뷰: 병합된 develop PR만 처리하는 조건, 공식 keyword 파싱, 같은 저장소 Issue 검증, API 실패 격리, marker 기반 멱등성, 최소 권한, PR Head 미실행을 확인했습니다. 로컬 모듈 실행 경로를 GITHUB_WORKSPACE와 main Checkout으로 명시했습니다.
• 2차 리뷰: AGENTS.md·CLAUDE.md, main 기본 브랜치와 Git Flow, 기존 CI, PR 템플릿 최소 변경, Secret/PAT 미사용, pull_request_target 미사용, Fork 제한, 문서·테스트 범위와 임시 파일 미포함을 재확인했습니다. Markdown 들여쓰기 코드 블록도 제외하도록 파서를 보완했습니다.

부트스트랩 및 후속 작업

• 이 PR은 자동화 도입을 위한 예외적인 main 대상 인프라 PR이며, develop의 미출시 기능을 포함하지 않습니다.
• 자동화 PR이 main에 병합된 이후부터 develop 병합 PR의 자동 종료가 활성화됩니다.
• 병합 후 main → develop 동기화가 필요합니다.
• 실제 운영 배포·기능 코드 변경·CD·Discord 알림·PR 자동 병합은 포함하지 않습니다.

---

✅ 체크리스트

• 문서(README, .env.example 등) 변경이 필요한 경우 작성 또는 수정했나요?
• 작업한 코드가 정상적으로 동작하는 것을 직접 확인했나요?
• 필요한 경우 테스트 코드를 작성하거나 수정했나요?
• Merge 대상 브랜치를 올바르게 설정했나요?
• PR에 관련 없는 작업이 포함되지 않았나요?
• 적절한 라벨과 리뷰어를 설정했나요?

---

📎 관련 이슈(선택)

• Closes develop 병합 PR의 연결 Issue 자동 종료 #36