[FEATURE] github action cicd를 위한 ci.yml 생성

[sunghun0917]

✨ 기능 설명
WAS 모듈에 대한 GitHub Actions 기반 CI/CD 파이프라인을 구축한다. 코드 푸시와 PR 시 테스트를 자동 수행하고, main 브랜치에 머지된 경우에는 Docker 이미지를 빌드해 푸시한 뒤 인프라 저장소에 배포 트리거를 전달한다.

🎯 배경 / 동기
백엔드 변경사항이 반영될 때마다 테스트, 빌드, 이미지 생성, 배포 트리거를 수동으로 수행하면 누락과 실수가 발생하기 쉽다. 특히 WAS는 배포 산출물이 bootJar와 Docker 이미지로 이어지므로, 브랜치 이벤트에 따라 검증과 배포 단계를 일관되게 자동화할 필요가 있다.

💡 제안하는 해결책
- .github/workflows/ci.yml에 WAS 전용 CI/CD 워크플로우를 둔다.
- 동작 방식:
- 모든 브랜치 push에 대해 테스트를 실행한다.
- dev, main 대상 PR에서도 테스트를 실행한다.
- Java 21과 Gradle 캐시를 설정한 뒤 ./gradlew test를 수행한다.
- 테스트 통과 후 ./gradlew bootJar로 배포 가능한 JAR를 생성한다.
- 이벤트가 main 브랜치에 대한 push일 때만 배포 메타데이터를 생성한다.
- 배포 대상인 경우 Docker Buildx를 설정하고 Docker Hub 로그인 후 Dockerfile로 이미지를 빌드/푸시한다.
- 이미지 태그는 main- 및 main을 함께 사용한다.
- 이미지 푸시가 끝나면 withrun/infra 저장소로 deploy-was repository dispatch 이벤트를 보내 실제 배포를 트리거한다.
- 동일 ref에 대한 중복 실행은 concurrency 설정으로 취소한다.

🔄 고려한 대안

• CI와 CD를 완전히 분리된 워크플로우로 운영한다. 현재는 테스트, 빌드, 배포 조건이 한 흐름으로 이어져 있어 단일 워크플로우가 관리와 추적에 더 단순하다.
• PR에서도 Docker 이미지를 매번 빌드한다. 검증 비용과 Docker Hub 사용량이 불필요하게 증가하므로, 실제 배포가 필요한 main push에만 제한한다.
• 애플리케이션 저장소에서 직접 배포까지 수행한다. 현재 구조는 인프라 저장소가 배포 책임을 가지므로, dispatch 기반 연동이 역할 분리에 더 적합하다.

✅ 완료 조건 (Acceptance Criteria)

• 모든 브랜치 push와 dev/main 대상 PR에서 WAS 테스트가 자동 실행된다.
• 테스트 통과 후 bootJar가 자동 생성된다.
• main 브랜치 push에서만 Docker 이미지가 빌드 및 Docker Hub에 푸시된다.
• 푸시된 이미지에 main-와 main 태그가 부여된다.
• main 브랜치 배포 대상 실행 시 withrun/infra로 deploy-was 이벤트가 전달된다.