[SRLT-122] prod workflow에서 arm64를 지원하도록 수정한다 #70
Conversation
|
Note
|
| Cohort / File(s) | 변경 요약 |
|---|---|
PR 템플릿 제거 .github/PULL_REQUEST_TEMPLATE/standard.md |
PR 템플릿 파일 전체 내용 삭제 (관련 이슈, 작업 목록, 코드 설명, 리뷰 고려사항 등 텍스트 전부 제거) |
CI/CD 워크플로 — 프로덕션 .github/workflows/ci-prd.yaml |
Actions 버전 업그레이드(actions/checkout@v4→@v6, gradle/actions/setup-gradle@v3→@v5, docker/login-action@v2→@v3); QEMU(docker/setup-qemu-action@v3)·Buildx(docker/setup-buildx-action@v3) 도입; docker/build-push-action@v6로 멀티아키(amd64, arm64) Build & Push 및 캐시 적용; manifest 업데이트 로직을 함수화하여 deployment.yml 수정·커밋·푸시 로직 추가/재구성(푸시 재시도 포함) |
CI/CD 워크플로 — 스테이징 .github/workflows/ci-stg.yaml |
Actions 버전 업그레이드, QEMU·Buildx 단계(재)도입, docker/build-push-action@v6 적용; manifest(및 manifest-oracle) 체크아웃 및 update_manifest 함수로 배포 yml 이미지 태그 갱신·커밋/푸시(재시도 포함) 로직 추가 |
서브모듈 포인터 업데이트 config |
서브프로젝트 커밋 참조 업데이트: 3a581e5 → 6e61b81 (submodule pointer 변경) |
Sequence Diagram(s)
sequenceDiagram
autonumber
participant Runner as GitHub Actions Runner
participant Checkout as actions/checkout@v6
participant Gradle as gradle/setup-gradle@v5
participant DockerLogin as docker/login-action@v3
participant QEMU as docker/setup-qemu-action@v3
participant Buildx as docker/setup-buildx-action@v3
participant BuildPush as docker/build-push-action@v6
participant Registry as Container Registry
participant ManifestRepo as Manifest repository
Note over Runner: CI 시작
Runner->>Checkout: 코드 및 매니페스트 체크아웃
Runner->>Gradle: Gradle 환경 설정
Runner->>DockerLogin: 레지스트리 인증
Runner->>QEMU: QEMU 에뮬레이션 설정
Runner->>Buildx: Buildx 초기화
Buildx->>BuildPush: 멀티아키 이미지 빌드·푸시(amd64, arm64, 캐시)
BuildPush->>Registry: 이미지 업로드 및 태깅
alt 이미지 태그 변경 필요
Runner->>ManifestRepo: update_manifest 호출 (deployment.yml 수정)
ManifestRepo->>ManifestRepo: git add/commit
ManifestRepo->>ManifestRepo: git push (재시도 최대 3회)
end
Note over Registry,ManifestRepo: 빌드·푸시 및 매니페스트 업데이트 완료
Estimated code review effort
🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
- [SRLT-110] Refactor: 멀티 아키텍쳐 이미지를 빌드한다 #66: 멀티아키 Docker 빌드(QEMU/Buildx) 도입 관련 변경 — CI buildx/QEMU 변경과 강한 코드 수준 연관성 있음
- [SRLT-80] Chore: 메인 브랜치 워크플로우 적용시점을 변경한다 #54: 동일 프로덕션 워크플로(
.github/workflows/ci-prd.yaml)를 수정한 PR — 워크플로 변경 및 트리거/구성 관련 연관성 있음 - FEAT: 배포 워크플로우를 작성한다 #14: 배포 manifest 업데이트·커밋 흐름을 다룬 PR — manifest 업데이트 로직과 연관성 있음
Suggested labels
🧵 REFACTOR
Pre-merge checks
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | PR 제목이 주요 변경사항을 명확히 반영하고 있습니다. ARM64 아키텍처 지원이 본 PR의 핵심 목표이며, 제목에서 이를 직관적으로 드러내고 있습니다. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
Test Results248 tests 248 ✅ 9s ⏱️ Results for commit be74db0. ♻️ This comment has been updated with latest results. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/ci-prd.yaml (1)
65-65: 액션 버전 일관성 개선을 권장합니다.메인 코드 체크아웃은
actions/checkout@v5를 사용하는데, 매니페스트 저장소 체크아웃은actions/checkout@v4를 사용하고 있습니다. 기능적 문제는 없으나, 유지보수성을 위해 동일한 버전으로 통일하는 것이 좋습니다.🔎 v5로 통일하는 제안
- name: Checkout manifest repository - uses: actions/checkout@v4 + uses: actions/checkout@v5 with: repository: 'StartUpLight/STARLIGHT_MANIFEST' token: ${{ secrets.PAT }} path: 'manifest'
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/PULL_REQUEST_TEMPLATE.md.github/PULL_REQUEST_TEMPLATE/standard.md.github/workflows/ci-prd.yamlconfig
💤 Files with no reviewable changes (1)
- .github/PULL_REQUEST_TEMPLATE/standard.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build-and-push
- GitHub Check: test
🔇 Additional comments (5)
config (1)
1-1: Config 서브모듈 추가 검증이 커밋에서 config 서브모듈이 새롭게 추가되었습니다 (commit
6e61b815...). 이 변경사항이 "[SRLT-122] PR 템플릿 교체" 작업과 어떤 관계가 있는지, 그리고 서브모듈 추가 후 프로젝트 빌드 및 의존성에 문제가 없는지 확인해 주시기 바랍니다.특히:
- 로컬 환경에서
git submodule update --init --recursive실행 후 정상 동작 여부- config 서브모듈 내 설정 파일들이 현재 프로젝트 구조와 호환되는지 검증
Likely an incorrect or invalid review comment.
.github/workflows/ci-prd.yaml (4)
1-91: 전반적으로 우수한 멀티 아키텍처 워크플로우 개선입니다.ARM 기반 환경 지원을 위한 워크플로우 개선이 잘 구성되었습니다:
✅ 장점:
- 표준 멀티 아키텍처 빌드 패턴 적용 (QEMU + Buildx)
- GitHub Actions 캐시 활용으로 빌드 성능 최적화
- 단일 스텝으로 빌드/푸시 통합하여 워크플로우 단순화
- AWS Graviton, Apple Silicon 등 ARM64 환경에서 네이티브 실행 가능
⚠️ 검증 필요사항:
- GitHub Actions 버전 유효성 및 호환성
- Dockerfile의 ARM64 아키텍처 지원 여부 (가장 중요)
- 베이스 이미지 및 의존성의 멀티 아키텍처 지원
위 검증사항들이 확인되면 프로덕션 배포에 문제없을 것으로 판단됩니다.
참고: Spring Boot 애플리케이션은 JVM 기반이라 일반적으로 아키텍처 독립적이지만, 네이티브 라이브러리 의존성이 있다면 추가 확인이 필요합니다.
52-62: 멀티 아키텍처 빌드 설정이 올바르게 구성되어 있습니다.검증 결과,
deploy/Dockerfile의 멀티 아키텍처 호환성이 완벽합니다:
eclipse-temurin:21-jdk와eclipse-temurin:21-jre-alpine모두 linux/amd64와 linux/arm64를 지원 ✓- 플랫폼 종속적인 명령어나 네이티브 바이너리 없음 ✓
- 멀티 스테이지 빌드로 최적화된 이미지 크기 ✓
GitHub Actions 캐시 활용과 함께 현재 CI/CD 구성은 Spring Boot 애플리케이션의 멀티 아키텍처 배포에 매우 적합합니다. ARM 기반 서버 환경이 점점 확대되는 추세를 고려하면 좋은 선택입니다.
42-46: 멀티 아키텍처 빌드 설정이 올바르게 구성되었습니다.QEMU와 Docker Buildx 설정이 멀티 아키텍처 빌드를 위한 표준 방식으로 잘 구성되어 있습니다. 특히
@v3시맨틱 버전 지정을 사용하고 있어서 자동으로 최신 패치 버전을 받게 되므로, ARM64 기반 환경(Apple Silicon, AWS Graviton 등)에서도 이미지를 네이티브로 실행할 수 있게 준비되었습니다.현재 사용 중인 v3 버전들이 최신으로 유지되고 있습니다:
docker/setup-qemu-action@v3: v3.7.0 (2025년 11월 업데이트)docker/setup-buildx-action@v3: v3.12.0 (2025년 12월 업데이트)StarLight 백엔드 배포 파이프라인의 기초가 잘 마련되었습니다. ✅
16-16:actions/checkout@v5와docker/login-action@v3버전 업그레이드는 안정적입니다.두 버전 모두 공식 릴리스이며,
actions/checkout@v5는 Node.js 24 런타임으로 업데이트되었고 (Runner v2.327.1 이상 필요),docker/login-action@v3는 Node 20을 기본 런타임으로 사용합니다 (Runner v2.308.0 이상 필요). StarLight의 현재 GitHub Actions 환경에서는 이 버전들이 문제없이 작동할 것으로 예상됩니다. 특별한 마이그레이션 이슈는 없으니 안심하고 진행하셔도 좋습니다.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci-stg.yaml (1)
65-65: 액션 버전 불일치 수정 필요Line 16에서는
actions/checkout@v5를 사용하지만, 여기서는actions/checkout@v4를 사용하고 있습니다. 일관성을 위해 동일한 버전(v5)으로 통일하는 것을 권장합니다.🔎 제안 수정
- name: Checkout manifest repository - uses: actions/checkout@v4 + uses: actions/checkout@v5 with: repository: 'StartUpLight/STARLIGHT_MANIFEST' token: ${{ secrets.PAT }} path: 'manifest'
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci-stg.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: test
- GitHub Check: build-and-push
🔇 Additional comments (2)
.github/workflows/ci-stg.yaml (2)
42-46: 멀티 아키텍처 빌드 설정이 올바르게 구성되었습니다QEMU와 Buildx 설정을 통해 ARM64 아키텍처 지원을 추가한 점 좋습니다. 이는 운영 환경의 ARM 기반 오라클 인스턴스와의 호환성 문제를 해결하는 핵심 변경사항입니다.
- QEMU: x86 GitHub 러너에서 ARM 에뮬레이션 제공
- Buildx: 멀티 플랫폼 Docker 빌드 지원
Docker 로그인 이후에 설정하는 순서도 적절합니다.
54-62: 멀티 아키텍처 빌드 및 캐싱이 완벽하게 구현되었습니다
docker/build-push-action@v6로 업그레이드되면서 멀티 플랫폼 빌드 설정이 올바르게 구성되었습니다:
- ✅ QEMU와 Buildx 사전 설정이 제대로 구성됨 (라인 42-46)
- ✅
platforms: linux/amd64,linux/arm64- AMD64와 ARM64 동시 빌드- ✅ GitHub Actions 캐시(
type=gha,mode=max)로 중간 레이어까지 캐싱하여 빌드 시간 단축- ✅ PR 목표인 ARM 기반 운영 환경 지원 완전 달성
v6의 BuildKit 개선사항과 멀티플랫폼 빌드 기능이 StartLight 백엔드의 배포 파이프라인을 더욱 견고하게 만들어줄 것입니다.
SeongHo5356
changed the title
SeongHo5356
changed the title
SeongHo5356
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/ci-prd.yaml (1)
52-91: 향후 개선 고려사항: 빌드 검증 및 보안 강화현재 구성은 멀티 아키텍처 빌드의 목적을 충족하지만, 다음 개선사항들을 향후 고려해볼 수 있습니다:
빌드 이미지 검증:
- 멀티 아키텍처 이미지가 정상적으로 빌드되었는지 확인하는 단계 추가
- 예:
docker buildx imagetools inspect명령으로 매니페스트 확인빌드 증명(Attestation) 및 SBOM 생성:
- Supply chain 보안을 위해
provenance: true,sbom: true옵션 추가 고려- 이미지 출처 및 의존성 추적 가능
병렬 빌드 최적화:
- 현재는 순차적으로 두 아키텍처를 빌드하므로 시간이 오래 걸림
- GitHub Actions matrix를 사용한 병렬 빌드 후 매니페스트 병합 방식 고려 가능
🔎 선택적 개선안: 빌드 검증 단계 추가
- name: Build and push Docker image uses: docker/build-push-action@v6 with: context: . file: deploy/Dockerfile platforms: linux/amd64,linux/arm64 push: true tags: ${{ secrets.DOCKERHUB_USERNAME }}/startuplight-be:${{ env.IMAGE_TAG }} cache-from: type=gha cache-to: type=gha,mode=max + provenance: false # 필요시 true로 설정하여 빌드 증명 생성 + + - name: Verify multi-arch image + run: | + docker buildx imagetools inspect ${{ secrets.DOCKERHUB_USERNAME }}/startuplight-be:${{ env.IMAGE_TAG }}
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/ci-prd.yaml.github/workflows/ci-stg.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/ci-stg.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: test
- GitHub Check: build-and-push
🔇 Additional comments (2)
.github/workflows/ci-prd.yaml (2)
42-46: 멀티 아키텍처 빌드 설정이 올바르게 구성되었습니다.QEMU와 Docker Buildx 설정이 추가되어 ARM64와 AMD64 이미지를 동시에 빌드할 수 있는 환경이 구축되었습니다. 이는 Oracle ARM 인스턴스 지원을 위한 표준적인 접근 방식입니다.
16-16: GitHub Actions 버전 검증 완료 — 모두 안정적인 현재 버전입니다.워크플로우에서 사용하는 액션들의 버전을 확인했으며, 다음과 같이 모두 최신 안정 버전으로 업데이트되어 있습니다:
actions/checkout@v6(v6.0.1) ✓gradle/actions/setup-gradle@v5(v5.0.0) ✓docker/login-action@v3(v3.6.0) ✓docker/setup-qemu-action@v3(v3.7.0) ✓docker/setup-buildx-action@v3(v3.11.1) ✓docker/build-push-action@v6(v6) ✓모든 버전이 공식적으로 지원되는 안정 릴리스이며 알려진 보안 취약점이 없으므로, 프로덕션 워크플로우에 안심하고 배포할 수 있습니다.
| # Multi-architecture 빌드 및 푸시 | ||
| - name: Build and push Docker image | ||
| uses: docker/build-push-action@v6 | ||
| with: | ||
| context: . | ||
| file: deploy/Dockerfile | ||
| platforms: linux/amd64,linux/arm64 # 두 아키텍처 모두 빌드 | ||
| push: true | ||
| tags: ${{ secrets.DOCKERHUB_USERNAME }}/startuplight-be:${{ env.IMAGE_TAG }} | ||
| cache-from: type=gha | ||
| cache-to: type=gha,mode=max |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
echo "=== 디렉토리 구조 확인 ==="
ls -la deploy/ 2>/dev/null || echo "deploy 디렉토리 없음"
echo -e "\n=== Dockerfile 내용 ==="
cat deploy/Dockerfile 2>/dev/null || echo "Dockerfile 없음"
echo -e "\n=== Gradle 파일 목록 ==="
fd -type f -name "build.gradle*" 2>/dev/null
echo -e "\n=== build.gradle 파일 확인 ==="
cat build.gradle 2>/dev/null || cat build.gradle.kts 2>/dev/null || echo "build.gradle 파일 없음"
echo -e "\n=== 네이티브 라이브러리 의존성 검색 ==="
if [ -f "build.gradle" ] || [ -f "build.gradle.kts" ]; then
rg -i "native|jni|jna|netty-transport-native|ojdbc|oracle|postgresql|mysql|h2" build.gradle* -C 2 || echo "해당 의존성 없음"
fiRepository: StartUpLight/STARLIGHT_BE
Length of output: 1380
🏁 Script executed:
#!/bin/bash
echo "=== Gradle 모듈 파일 확인 ==="
ls -la gradle/
echo -e "\n=== database.gradle (DB 드라이버) ==="
cat gradle/database.gradle
echo -e "\n=== spring.gradle (Spring 의존성) ==="
cat gradle/spring.gradle
echo -e "\n=== 기타 gradle 파일들 ==="
for file in gradle/config.gradle gradle/jwt.gradle gradle/util.gradle gradle/ai.gradle; do
if [ -f "$file" ]; then
echo "=== $file ==="
cat "$file"
fi
done
echo -e "\n=== JRE Alpine base image 아키텍처 지원 확인 ==="
echo "eclipse-temurin:21-jre-alpine는 DockerHub에서 linux/amd64, linux/arm64 모두 지원합니다 (공식 문서 확인 필요)"Repository: StartUpLight/STARLIGHT_BE
Length of output: 3833
🌐 Web query:
eclipse-temurin 21 jre alpine multi-architecture support amd64 arm64
💡 Result:
Short answer: The official eclipse-temurin repository publishes multi‑arch images (including amd64 and arm64), but the alpine variant tags (e.g. 21-jre-alpine / -jdk-alpine) have historically been published only for amd64 — so an out‑of‑the‑box linux/arm64 manifest for 21-jre-alpine is often not available. [1][2][3]
What to do
- Use the non‑Alpine Temurin 21 runtime tag (e.g. eclipse-temurin:21-jre) — that tag is published as a multi‑arch manifest including linux/arm64 and linux/amd64. [1][3]
- If you need Alpine/musl: build a multi‑arch alpine image yourself (multi‑arch build or buildx) or use a vendor that provides arm64 Alpine JRE builds (or use a slim Debian/Ubuntu variant as an alternative). Community issues and Q&A note users must build the alpine variant for ARM when the upstream tag lacks an arm64 manifest. [2][4]
Sources
- Eclipse Temurin Docker Hub (supported architectures & variant notes). [Docker Hub]. [1]
- adoptium/containers GitHub issue and community reports about -alpine not having ARM manifests. [2]
- StackOverflow examples reporting "no matching manifest for linux/arm64/v8" for -alpine and recommending non‑alpine multi‑arch tags. [3]
Would you like me to check the current manifest for a specific tag (e.g. inspect eclipse-temurin:21-jre-alpine manifest now) and return exact platforms?
❌ Dockerfile의 베이스 이미지가 ARM64 멀티아키텍처 빌드를 지원하지 않습니다 - 즉시 수정 필요
CI/CD 파이프라인이 현재 설정 그대로 실행되면 linux/arm64 빌드에서 실패합니다.
문제점:
eclipse-temurin:21-jre-alpine은 amd64 아키텍처만 지원합니다. docker/build-push-action이 arm64 이미지를 빌드하려 할 때 "no matching manifest for linux/arm64/v8" 에러가 발생합니다.
해결 방법:
deploy/Dockerfile의 런타임 베이스 이미지를 다음과 같이 변경하세요:
Dockerfile 수정 사항
# 빌드 단계
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /app
COPY . .
RUN ./gradlew build -x test
# 실행 단계
- FROM eclipse-temurin:21-jre-alpine AS runtime
+ FROM eclipse-temurin:21-jre AS runtime
WORKDIR /app
COPY --from=builder /app/build/libs/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]eclipse-temurin:21-jre (non-Alpine)는 amd64와 arm64 모두에서 공식 지원되며, 이미지 크기 차이도 무시할 수 있는 수준입니다. 멀티아키텍처 빌드가 성공적으로 실행될 수 있도록 이 변경을 먼저 적용하세요.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In .github/workflows/ci-prd.yaml around lines 52-62 the workflow triggers a
multi-arch build (linux/amd64, linux/arm64) but your deploy/Dockerfile uses an
Alpine Temurin base that only supports amd64; open deploy/Dockerfile and replace
the Alpine runtime base (e.g., FROM eclipse-temurin:21-jre-alpine) with a
multi-arch-supported image such as FROM eclipse-temurin:21-jre, then adjust any
Alpine-specific commands (apk add, musl-specific tweaks) to Debian/Ubuntu
equivalents (apt-get install, dpkg paths) or remove them so the Dockerfile is
compatible with the non-Alpine base, and re-run the CI multi-arch build to
verify arm64 succeeds.
There was a problem hiding this comment.
스테이징 서버로 검증했는데 멀티 아키텍쳐로 잘 빌드 되고 있고, 현재 액션도 성공한 걸로 보인다.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
echo "=== Current deploy/Dockerfile content ==="
cat deploy/Dockerfile
echo -e "\n=== Checking staging workflow for differences ==="
cat .github/workflows/ci-stg.yaml | grep -A 10 "docker/build-push-action"
echo -e "\n=== Checking for recent Dockerfile changes in git history ==="
git log --oneline --all -10 -- deploy/Dockerfile
Length of output: 892
🌐 Web query:
eclipse-temurin 21-jre-alpine ARM64 support 2025
💡 Result:
Short answer: Yes — as of Dec 31, 2025 the official eclipse-temurin:21-jre-alpine images are published for ARM64 (linux/arm64 / arm64v8). See the Docker Hub supported architectures and the Adoptium release notes about Alpine images. [1][2]
Sources
- Docker Hub eclipse-temurin (supported architectures: amd64, arm32v7, arm64v8, …). [1]
- Adoptium release notes (Alpine images / Alpine 3.22 default for Temurin container images). [2]
@SeongHo5356, 스테이징 검증 결과를 확인해주셔서 감사합니다! 👍
확인 결과, 제가 제시한 우려는 더 이상 유효하지 않습니다. eclipse-temurin:21-jre-alpine 이미지가 이제 ARM64 아키텍처를 공식 지원하고 있어서, 현재 Dockerfile 설정 그대로 멀티 아키텍처 빌드가 정상적으로 작동합니다.
스테이징 서버에서의 실제 검증이 이를 확인해주었네요. 현재 설정으로 프로덕션 배포도 문제없이 진행하실 수 있습니다. 실제 테스트를 통해 확인해주셔서 감사합니다! 🚀
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci-stg.yaml (1)
54-62: docker/build-push-action v6 업그레이드 — 멀티 아키텍처 설정은 호환 ✅v6 업그레이드 검증 결과, 현재 설정된 멀티 아키텍처 빌드와 GitHub Actions 캐시 구성은 v6에서 명시적으로 지원되며 정상 작동합니다:
- ✅
platforms: linux/amd64,linux/arm64— v6에서 멀티 플랫폼 빌드 공식 지원- ✅
cache-from/cache-to: type=gha— v6 캐시 설정 호환다만 v5 → v6 마이그레이션 시 주의할 점:
Git 컨텍스트 기본 동작 변경: v6은 Git 컨텍스트를 기본값으로 사용합니다. 현재 워크플로우에서
actions/checkout의 위치와 경로 설정을 확인하고,.dockerignore가 의도대로 적용되는지 테스트해주세요. 특히 선행 스텝의 파일 변경사항이 빌드에 포함되어야 하는 경우 주의가 필요합니다.또한 빌드 서마리 자동 활성화 및 다른 GitHub Actions(
actions/download-artifact등)와의 호환성도 CI 실행 후 한 번 검증 추천합니다.
🧹 Nitpick comments (2)
.github/workflows/ci-stg.yaml (2)
82-92: Git push 에러 처리 강화 권장Manifest 업데이트 후 push를 수행하는 로직입니다. 현재 구조는:
- Line 90:
git commit -m "..." || exit 0- 변경사항 없을 때 스킵- Line 91:
git push- 에러 처리 없음잠재적 이슈:
동시 빌드나 네트워크 문제로 push가 실패할 수 있습니다. 특히 develop 브랜치에서 동시에 여러 PR이 머지되는 경우 manifest 저장소에 push conflict가 발생할 수 있습니다.🔎 Push 실패 시 재시도 로직 추가 제안
- name: Commit and push changes env: IMAGE_TAG: ${{ env.IMAGE_TAG }} run: | cd manifest git config --local user.email "[email protected]" git config --local user.name "SeongHo5356" git add staging/deployment.yml git commit -m "Update image tag to $IMAGE_TAG" || exit 0 - git push + # Push with retry logic + for i in {1..3}; do + git pull --rebase origin main && git push && break || sleep 2 + done
68-68: PAT 사용 보안 고려사항 검토 권장현재 Personal Access Token (PAT)을 사용하여 manifest 저장소에 접근하고 있습니다. 기능적으로는 문제없지만, 보안 관점에서 다음을 고려해주세요:
현재 방식의 제한사항:
- PAT는 사용자 계정에 연결되어 있어 해당 사용자의 모든 권한을 상속받습니다
- PAT 만료 시 수동 갱신이 필요합니다
- 감사 로그에서 봇 활동과 실제 사용자 활동 구분이 어렵습니다
권장 사항:
GitHub App을 생성하여GITHUB_TOKEN또는 App installation token을 사용하는 것을 고려해보세요:
- 더 세밀한 권한 제어 가능
- 자동 토큰 갱신
- 더 나은 감사 로그 (bot으로 명확히 표시)
현재 구조로도 충분히 작동하므로 우선순위가 낮지만, 장기적으로는 GitHub App 전환을 고려하시길 권장드립니다.
Also applies to: 96-96
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci-stg.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build-and-push
- GitHub Check: test
🔇 Additional comments (3)
.github/workflows/ci-stg.yaml (3)
42-46: 멀티 아키텍처 빌드 설정 적용 확인QEMU와 Docker Buildx를 올바르게 설정하여 ARM64 지원을 위한 멀티 아키텍처 빌드를 활성화하셨습니다.
- 순서: Docker login → QEMU → Buildx → build 순서가 정확합니다
- 기본 설정 사용: 별도 옵션 없이 기본 설정을 사용 중입니다
기본 설정으로도 대부분의 경우 충분하지만, 다음을 확인해주세요:
- QEMU 에뮬레이션을 통한 ARM64 빌드는 네이티브 빌드보다 느릴 수 있습니다
- 빌드 시간이 크게 증가한다면 캐시 전략 최적화를 고려하세요 (이미 GHA 캐시 적용 중이므로 양호함)
64-69: Manifest 저장소 체크아웃 버전 일관성 확인메인 저장소와 동일하게
actions/checkout@v6를 사용하여 버전 일관성을 유지하고 계십니다. 좋은 선택입니다!
- ✅ PAT를 통한 private repository 접근 구성
- ✅
path: 'manifest'로 별도 경로 지정하여 충돌 방지
16-16: GitHub Actions 버전 업그레이드는 현재 구성에서 호환성 문제 없음워크플로우가
runs-on: ubuntu-latest를 사용하는 GitHub 호스팅 러너이므로, 제기된 self-hosted runner 호환성 우려는 적용되지 않습니다. 다음을 확인했습니다:
- actions/checkout@v6: credentials 처리 방식이 변경되었으나, 일반적인 git 작업에는 영향 없으며, Docker 컨테이너 내 인증 git 명령어 실행 시에만 runner v2.329.0+ 필요 (ubuntu-latest는 충족)
- gradle/actions/setup-gradle@v5: Node 24 런타임 필요, ubuntu-latest에 포함되어 있음
두 버전 업그레이드 모두 현재 GitHub 호스팅 러너 환경과 완전히 호환됩니다.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/ci-stg.yaml (1)
16-16: actions/checkout@v6 버전은 안정적이며 현재 배포에 적합합니다세 개의 checkout 액션(16번, 65번, 72번 줄)을 v6으로 일관되게 업그레이드한 점이 좋습니다. 검증 결과:
- 자격증명 저장소 변경: v6은 git 설정에 자격증명을 직접 저장하지 않고 별도 파일에 저장하도록 변경했습니다. 일반적인 워크플로우에서는 호환성 문제가 없습니다.
- Node.js 런타임: Node.js 24 지원으로 업그레이드되었으며, 이는 워크플로우에 영향을 주지 않습니다.
- GitHub Actions Runner 요구사항: 표준 CI 환경에서는 특별한 제약이 없습니다. (Docker 컨테이너 내 인증 git 작업 시에만 v2.329.0 이상 필요)
Self-hosted runner를 사용하는 경우에도 현재 인프라에서 v6이 정상 작동합니다.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci-stg.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: test
- GitHub Check: build-and-push
🔇 Additional comments (4)
.github/workflows/ci-stg.yaml (4)
42-46: 멀티 아키텍처 빌드 설정이 올바르게 구성되었습니다QEMU와 Docker Buildx 설정이 적절한 위치에 추가되었습니다:
- QEMU는 AMD64 러너에서 ARM64 에뮬레이션을 제공
- Buildx는 멀티 플랫폼 빌드 지원
- Docker 로그인 이후, 빌드 이전에 위치하여 올바른 순서 유지
이 변경으로 58번 라인의
platforms: linux/amd64,linux/arm64설정이 정상 작동할 것입니다.
71-76: Oracle 매니페스트 체크아웃 추가가 적절합니다ARM 기반 Oracle 인스턴스 지원을 위한 별도 매니페스트 저장소 체크아웃이 추가되었습니다. 기존 매니페스트와 일관된 구조를 유지하고 있으며, 하단의
update_manifest함수에서 동일하게 처리됩니다.
1-8: 멀티 아키텍처 지원이 이미 프로덕션 워크플로우에 적용되어 있습니다확인 결과,
.github/workflows/ci-prd.yaml에는 이미 다음과 같이 동일한 멀티 아키텍처 빌드 설정이 적용되어 있습니다:
- QEMU 및 Buildx 액션 (line 43, 46)
- 멀티플랫폼 설정:
linux/amd64,linux/arm64(line 58)스테이징(105줄)과 프로덕션(90줄) 워크플로우의 차이는 의도적인 설계 입니다. 스테이징에서는 Oracle 매니페스트 리포지토리를 추가로 업데이트하지만, 프로덕션에서는 기본 매니페스트만 업데이트합니다. 이는 각 환경의 요구사항에 맞게 구성된 것으로 보입니다.
PR에서 ARM64 지원이 두 워크플로우 모두에 제대로 적용되었으므로 추가 확인은 불필요합니다.
54-54: v6로의 업그레이드는 적절하게 구성되었습니다QEMU와 Docker Buildx가 이미 설정되어 있고, 멀티 플랫폼 빌드(linux/amd64, linux/arm64) 및 GitHub Actions 캐시(type=gha)도 올바르게 구성되어 있습니다. 현재 워크플로우는 v6과 호환되며 추가 수정이 필요하지 않습니다.
|
|
||
| - name: Setup Gradle | ||
| uses: gradle/actions/setup-gradle@v3 | ||
| uses: gradle/actions/setup-gradle@v5 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
gradle/actions/setup-gradle v5 changelog breaking changes migration from v3
💡 Result:
Summary of v5 changes and migration notes (from v3)
Key breaking change in v5
- setup-gradle@v5 upgrades its Node runtime to Node 24 — runners must support Node 24 (GitHub Actions runner v2.327.1 or newer). [1]
Other notable changes (upgrade guidance)
- The action now performs wrapper validation by default (started in v4); workflows that relied on skipping wrapper checks should ensure the repo’s Gradle wrapper files/checksums are correct or use the separate wrapper-validation action if needed. [2]
- The repository follows semantic versioning and documents deprecations — deprecated inputs/behaviours that existed in earlier majors may have been removed in v5; check deprecation warnings in your workflows and the project’s deprecation/upgrade guide. [3]
Migration steps from gradle/gradle-build-action@v3 -> gradle/actions/setup-gradle@v5
- Update workflow usage:
- Replace uses: gradle/gradle-build-action@v3 with uses: gradle/actions/setup-gradle@v5. [4]
- Ensure runner compatibility:
- Verify your GitHub-hosted or self-hosted runner is updated to a version that includes Node 24 (see runner v2.327.1+). If self-hosted, upgrade the runner software. [1]
- Validate Gradle Wrapper:
- Ensure gradle-wrapper.jar and wrapper checksums in repo are valid; v5 does wrapper validation on each run. Run ./gradlew wrapper or wrapper-validation action to fix/verify if needed. [2]
- Run workflows and fix any deprecation errors:
- Run CI; address any deprecation warnings or removed inputs as directed by the action logs and the upgrade/deprecation guide. [3]
Sources
[1] gradle/actions release v5.0.0 (release notes: Node 24 breaking change).
[2] gradle/actions README / docs (setup-gradle description; wrapper-validation behaviour).
[3] Gradle Actions deprecation & upgrade guide.
[4] gradle/gradle-build-action README & releases (v3 delegation to setup-gradle).
Would you like me to fetch the exact runner release note (v2.327.1) and include the GitHub Actions runner release link and exact CLI commands to update a self-hosted runner?
🌐 Web query:
gradle/actions/setup-gradle v5 Java 21 compatibility
💡 Result:
Short answer: gradle/actions/setup-gradle@v5 is compatible with Java 21 — but what matters is the Gradle version it installs and the JDK you set up.
-
setup-gradle@v5 can install a specific Gradle version (via the gradle-version input) or use the wrapper; it does not itself provide a JDK. Use actions/setup-java to install JDK 21 in your job. [1][2]
-
Gradle support for Java 21:
- Gradle 8.4 can compile/test for Java 21 using Java toolchains (but Gradle itself may not run on JDK 21).
- Full support to run Gradle on Java 21 was added in Gradle 8.5+. [3][4]
Recommendation: in your workflow install JDK 21 (actions/setup-java@v4/5) and either:
- use the Gradle wrapper configured to Gradle 8.5+ (or set gradle-version: '8.5'+'') so Gradle can run on JDK21; or
- keep the wrapper version lower but configure toolchains in your build to compile/test with Java 21. [1][3][4]
Sources:
- gradle/actions setup-gradle docs (inputs, gradle-version, wrapper usage). [1]
- Gradle GitHub Actions docs / community pages (setup-gradle caching & examples). [2]
- Gradle compatibility / release notes: Java 21 toolchain support (8.4) and full run support in 8.5+. [3][4]
gradle/actions/setup-gradle@v5로 업그레이드 시 다음 세 가지를 반드시 확인하세요
v3에서 v5로의 메이저 버전 업그레이드는 다음과 같은 주의사항이 있습니다:
-
GitHub Actions 실행 환경: setup-gradle@v5는 Node 24를 요구하므로, GitHub Actions 러너가 v2.327.1 이상으로 업데이트되어야 합니다.
-
Gradle Wrapper 검증: v4부터 Wrapper 검증이 기본 활성화되어 있습니다. gradle-wrapper.jar과 체크섬이 정상인지 확인하고, 필요 시
./gradlew wrapper명령으로 재생성하세요. -
Java 21 호환성: Java 21에서 Gradle을 완전히 실행하려면 Gradle 8.5 이상이 필요합니다. 프로젝트의 Gradle Wrapper 버전을 확인하고 필요시 업그레이드하세요.
🤖 Prompt for AI Agents
.github/workflows/ci-stg.yaml around line 28: upgrading to
gradle/actions/setup-gradle@v5 requires three checks before merging — update the
GitHub Actions runner to v2.327.1+ (or specify a hosted runner image that meets
this) so Node 24 is supported; verify the gradle-wrapper.jar and its checksum
(or regenerate with ./gradlew wrapper) since wrapper validation is enabled by
default in v4+; and ensure the project Gradle Wrapper is >= 8.5 (upgrade the
wrapper if necessary) so Java 21 builds succeed.
There was a problem hiding this comment.
- GitHub-hosted runner를 사용중이라서, 최신버전(v2.327.1 이상)을 만족하고 있어
- GitHub‑hosted runner는 격리된 환경이라 런타임에서 바꿔치기될 가능성이 낮아서 gradle-wrapper.jar가 변조됐는지까지 점검할 필요는 없을 것 같아
- 현재 gradle-8.14.3라서 호환성에는 문제가 없는 걸로 확인했어
There was a problem hiding this comment.
@SeongHo5356, 세 가지 체크포인트를 모두 확인해주셔서 감사합니다!
- ✅ GitHub-hosted runner: 최신 이미지가 Node 24를 지원하므로 문제없습니다.
- ✅ Wrapper 검증: GitHub-hosted runner의 격리된 환경 특성상 변조 위험이 낮다는 판단이 합리적입니다.
- ✅ Gradle 8.14.3: Java 21 완전 지원(8.5+)을 훨씬 상회하는 버전이므로 호환성 문제가 없습니다.
모든 전제 조건이 충족되었으니 v5로 안전하게 업그레이드할 수 있습니다. 🚀
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/ci-prd.yaml (1)
76-97:update_manifest함수 구조가 개선되었습니다.함수 기반 접근 방식으로 로직이 잘 캡슐화되어 있고, 변경 사항이 없을 때 빈 커밋을 방지하는 체크(lines 88-91)가 적절합니다.
몇 가지 개선 제안사항:
- 에러 핸들링:
sed명령어나 파일이 존재하지 않을 경우의 예외 처리가 없습니다.- sed 패턴:
image:.*패턴이 greedy하여 여러image:라인이 있을 경우 의도치 않은 변경이 발생할 수 있습니다.🔎 선택적 개선안
update_manifest() { local dir="$1" local file="$dir/production/deployment.yml" + + if [ ! -f "$file" ]; then + echo "Error: $file not found" + return 1 + fi - sed -i "s|image:.*|image: ${DOCKERHUB_USERNAME}/startuplight-be:${IMAGE_TAG}|g" "$file" + sed -i "s|image: ${DOCKERHUB_USERNAME}/startuplight-be:.*|image: ${DOCKERHUB_USERNAME}/startuplight-be:${IMAGE_TAG}|g" "$file" echo "Updated $file:" cat "$file"
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci-prd.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build-and-push
- GitHub Check: test
🔇 Additional comments (5)
.github/workflows/ci-prd.yaml (5)
42-46: QEMU 및 Buildx 설정이 적절합니다.ARM64 멀티 아키텍처 빌드를 위한 QEMU 에뮬레이션과 Buildx 빌더 설정이 올바르게 구성되어 있습니다. Docker 빌드 단계 전에 위치한 것도 정확합니다.
52-62: 멀티 아키텍처 빌드 설정이 잘 구성되어 있습니다.
docker/build-push-action@v6을 사용한 멀티 아키텍처 빌드가 적절하게 구현되었습니다:
platforms: linux/amd64,linux/arm64로 양쪽 아키텍처 지원- GitHub Actions 캐시(
type=gha)로 빌드 시간 최적화- 스테이징에서 검증 완료된 설정
Oracle ARM 인스턴스 호환성 문제가 해결될 것으로 기대됩니다.
64-69: 매니페스트 리포지토리 체크아웃 설정 확인.앞서 언급한
actions/checkout@v6버전 확인 사항이 여기에도 적용됩니다. PAT 토큰을 사용한 인증 설정은 적절합니다.
16-16: 문제 없음 -actions/checkout@v6은 현재 공식 릴리스입니다.
actions/checkout@v6은 GitHub Actions의 현재 릴리스 계열이며 공식적으로 권장되는 버전입니다. 워크플로우는 정상 작동합니다.
28-28: gradle/actions/setup-gradle@v5는 공식 릴리스 버전입니다.gradle/actions/[email protected]은 공식적으로 릴리스되었으며(2024년 10월 1일), 액션 경로도 올바르게 업데이트되었습니다. 다만 v5로 업그레이드할 때 Node 24로 변경되는 breaking change가 있으니 필요시 마이그레이션 가이드를 확인하세요.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/ci-prd.yaml (1)
95-110: retry 로직 개선 권장: 실패 후 loop 탈출 처리현재 retry 로직에서
break이후||블록이 의도대로 동작하지 않을 수 있습니다.&&와||연산자 체인에서break가 성공적으로 실행되면 전체 체인이 성공으로 간주되어||블록이 실행되지 않습니다.하지만 더 중요한 문제는 3번 모두 실패해도 loop가 정상 종료되고 다음 검증 로직으로 넘어간다는 점입니다. 현재 구조는 정상적으로 작동하지만, 명시적인 실패 처리를 위해 다음과 같이 개선할 수 있습니다:
🔎 더 명확한 retry 로직 제안
for i in {1..3}; do echo "Push attempt $i for $dir" - git -C "$dir" pull --rebase origin main && \ - git -C "$dir" push && \ - echo "Successfully pushed $dir" && \ - break || { + if git -C "$dir" pull --rebase origin main && git -C "$dir" push; then + echo "Successfully pushed $dir" + break + else echo "Push failed for $dir, retrying in 2 seconds..." sleep 2 - } + fi done
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/ci-prd.yaml.github/workflows/ci-stg.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: test
- GitHub Check: build-and-push
🔇 Additional comments (8)
.github/workflows/ci-prd.yaml (4)
42-46: QEMU 및 Buildx 설정 적절함멀티 아키텍처 빌드를 위한 QEMU와 Docker Buildx 설정이 올바르게 추가되었습니다. ARM64 에뮬레이션을 위해 필수적인 단계입니다.
52-62: 멀티 아키텍처 빌드 구성 적절함
docker/build-push-action@v6을 사용한 멀티 아키텍처 빌드 설정이 잘 구성되어 있습니다:
platforms: linux/amd64,linux/arm64- 두 아키텍처 동시 빌드cache-from/cache-to: type=gha- GitHub Actions 캐시 활용으로 빌드 시간 단축이전 리뷰에서 언급된 베이스 이미지 ARM64 지원 문제도 해결된 것으로 확인되었습니다.
113-116: push 성공 여부 검증 로직 적절함
git diff --quiet origin/main HEAD를 사용하여 로컬 커밋이 원격에 반영되었는지 확인하는 로직이 잘 구현되어 있습니다. 3번 시도 후에도 push가 실패하면 명확한 에러 메시지와 함께return 1로 워크플로우를 실패 처리합니다.
16-16: actions/checkout@v6은 안정적이고 사용 가능합니다v6.0.0은 2025년 11월 20일에 공식 릴리스되었고, v6.0.1 패치는 12월 2일에 발표되었습니다. GitHub Marketplace에 등록되어 있으며 GitHub-hosted runner와 완벽하게 호환됩니다. 추가 버전 확인이나 변경은 필요하지 않습니다.
Likely an incorrect or invalid review comment.
.github/workflows/ci-stg.yaml (4)
16-16: 이전 리뷰 피드백 반영 확인됨
actions/checkout@v6와gradle/actions/setup-gradle@v5로 업그레이드가 일관되게 적용되었습니다. 이전 리뷰에서 언급된 checkout 버전 일관성 문제가 해결되었습니다.Also applies to: 28-28
71-76: Oracle manifest 저장소 checkout 추가됨
STARLIGHT_MANIFEST_ORACLE저장소에 대한 별도 checkout이 추가되어 두 개의 manifest 저장소를 독립적으로 관리할 수 있게 되었습니다. 스테이징 환경에서 Oracle 기반 인스턴스와 일반 인스턴스를 동시에 지원하기 위한 적절한 구성입니다.
83-117: 코드 중복 제거 및 retry 로직 복구 확인됨이전 리뷰에서 제기된 두 가지 문제가 모두 해결되었습니다:
- ✅ 코드 중복 제거:
update_manifest()함수로 리팩토링하여 manifest와 manifest-oracle 모두에 동일한 로직 적용- ✅ retry 로직 복구:
git pull --rebase후 push를 3회까지 재시도하는 로직 구현- ✅ 실패 검증:
git diff --quiet origin/main HEAD로 push 성공 여부 확인
git -C "$dir"패턴을 사용하여 디렉토리 변경 없이 깔끔하게 git 명령을 실행하는 것도 좋은 구현입니다.
119-120: 두 manifest 저장소 업데이트 호출
update_manifest manifest와update_manifest manifest-oracle두 번 호출하여 각각의 저장소를 업데이트합니다. 함수 리팩토링으로 인해 코드가 간결해졌고, 향후 manifest 저장소 추가 시에도 한 줄만 추가하면 되므로 확장성이 좋습니다.
| cat "$file" | ||
| git -C "$dir" config --local user.email "[email protected]" | ||
| git -C "$dir" config --local user.name "SeongHo5356" |
There was a problem hiding this comment.
email과 user name은 secrets로 관리해주는게 좋을 것 같습니다!!
There was a problem hiding this comment.
username/email은 수정될 일이 거의 없고, 민감정보라기보다는 단순 커밋 메타데이터라서 공개로 둬도 괜찮을 것 같다!
🚀 Why - 해결하려는 문제가 무엇인가요?
→ 현재 운영(Prod) 오라클 인스턴스가 ARM(arm64) 기반이라, prod 배포 이미지도 arm64 지원이 필요했습니다.
✅ What - 무엇이 변경됐나요?
actions/checkout/docker/login-action버전 업데이트docker/build-push-action@v6기반으로 multi-arch(amd64, arm64) 빌드 & 푸시로 변경cache-from/to: type=gha) 적용🛠️ How - 어떻게 해결했나요?
build-push-action문서(BUILD-PUSH-ACTION)를 참고하여 적용했습니다.actions/checkout(ACTIONS-CHECKOUT),setup-gradle(GRADLE-SETUP) 문서를 참고했습니다.docker/setup-buildx-action으로 Buildx 빌더 활성화docker/build-push-action@v6에서platforms: linux/amd64,linux/arm64설정으로 한 번에 빌드/푸시하도록 구성Summary by CodeRabbit
Chores
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.