chore(server): 서버 배포 인프라 세팅 초기 작업 (#47) - #77
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughserver 변경에 반응하는 PR 검증 CI와 main 배포용 GitHub Actions 워크플로우가 추가되었고, 운영 인프라와 배포 구성이 CLAUDE.md에 문서화되었다. Changes서버 CI/CD 자동화
운영 인프라 문서
Estimated code review effort: 3 (Moderate) | ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/server-deploy.yml (1)
26-28: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winGradle 의존성 캐싱 미적용.
매 배포마다 전체 의존성을 새로 다운로드하게 되어 빌드 시간이 늘어납니다.
actions/setup-java의cache: gradle옵션이나gradle/actions/setup-gradle을 활용하면 빌드 시간을 단축할 수 있습니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/server-deploy.yml around lines 26 - 28, The Gradle build step in the server deploy workflow is missing dependency caching, so update the job that uses actions/setup-java or add gradle/actions/setup-gradle to enable Gradle cache support before the Build with Gradle step. Configure the workflow to reuse downloaded dependencies across runs by setting cache: gradle or using the Gradle setup action, and keep the existing build command under the same build job.CLAUDE.md (1)
31-32: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value운영 인프라의 실제 IP/엔드포인트가 문서에 하드코딩되어 있습니다.
탄력적 IP와 RDS 엔드포인트 호스트명을 저장소에 커밋된 마크다운에 그대로 노출하면, 저장소가 향후 공개되거나 포크될 경우 공격 표면 정찰에 활용될 수 있습니다. 내부 위키/시크릿 매니저 등 접근이 제한된 곳에 두는 것을 고려해보세요.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@CLAUDE.md` around lines 31 - 32, The CLAUDE.md deployment notes hardcode live EC2 and RDS network identifiers, so move those values out of the repository into a restricted internal source such as an internal wiki or secret/config management system. Update the document to remove the actual elastic IP and RDS endpoint, and keep only generic guidance; if needed, reference the affected infrastructure entries by their EC2 and RDS labels so they can still be located and maintained.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/server-deploy.yml:
- Line 14: The actions/checkout@v4 step in the server deployment workflow is
leaving git credentials persisted by default, which is unnecessary here. Update
the checkout configuration to explicitly disable credential persistence by
setting persist-credentials to false on the checkout step, so the workflow does
not retain reusable git auth for later steps.
- Around line 30-38: The Copy JAR to EC2 step is stripping too few path
components for the server/build/libs/*.jar source, which leaves the uploaded JAR
under an extra libs directory and prevents the deploy flow from finding it.
Update the appleboy/scp-action configuration in the Copy JAR to EC2 job to use
strip_components with the correct value so the JAR lands directly in
/home/ec2-user/app and can be picked up by the later find-based app.jar refresh
logic.
---
Nitpick comments:
In @.github/workflows/server-deploy.yml:
- Around line 26-28: The Gradle build step in the server deploy workflow is
missing dependency caching, so update the job that uses actions/setup-java or
add gradle/actions/setup-gradle to enable Gradle cache support before the Build
with Gradle step. Configure the workflow to reuse downloaded dependencies across
runs by setting cache: gradle or using the Gradle setup action, and keep the
existing build command under the same build job.
In `@CLAUDE.md`:
- Around line 31-32: The CLAUDE.md deployment notes hardcode live EC2 and RDS
network identifiers, so move those values out of the repository into a
restricted internal source such as an internal wiki or secret/config management
system. Update the document to remove the actual elastic IP and RDS endpoint,
and keep only generic guidance; if needed, reference the affected infrastructure
entries by their EC2 and RDS labels so they can still be located and maintained.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 392f4734-083f-4935-8b81-a106a8f53ecb
📒 Files selected for processing (2)
.github/workflows/server-deploy.ymlCLAUDE.md
| - name: Copy JAR to EC2 | ||
| uses: appleboy/scp-action@v0.1.7 | ||
| with: | ||
| host: ${{ secrets.EC2_HOST }} | ||
| username: ${{ secrets.EC2_USER }} | ||
| key: ${{ secrets.EC2_SSH_KEY }} | ||
| source: 'server/build/libs/*.jar' | ||
| target: '/home/ec2-user/app' | ||
| strip_components: 2 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== Workflow file ==\n'
git ls-files '.github/workflows/server-deploy.yml' && {
echo '---'
cat -n .github/workflows/server-deploy.yml | sed -n '1,140p'
}
printf '\n== Find relevant server build paths ==\n'
git ls-files 'server/**' | sed -n '1,200p'
printf '\n== Search for strip_components / rm usage ==\n'
rg -n --hidden --glob '!.git' 'strip_components|appleboy/scp-action|rm:\s*true|find \.|app\.jar|server/build/libs' .
printf '\n== appleboy/scp-action docs hint in repo (if any) ==\n'
rg -n --hidden --glob '!.git' 'strip_components' .github README.md docs . || trueRepository: thumbsup-studio/thumbsup
Length of output: 2955
🌐 Web query:
appleboy/scp-action strip_components glob source path behavior
💡 Result:
In the appleboy/scp-action, the strip_components parameter is designed to remove a specified number of leading path elements from the source files when they are extracted on the remote server [1][2]. It expects a numeric value representing the number of directory levels to strip [1][2]. Regarding its behavior and interaction with source paths: 1. Numerical Requirement: Users should provide a positive integer (e.g., 1, 2) rather than a boolean [2]. While some users have reported success using "true" in specific scenarios, this is non-standard [3]. 2. Path Sensitivity: The number of components to strip is highly dependent on the absolute path of the source directory within the runner environment [4]. Because GitHub Actions runners often use nested path structures (e.g., /home/runner/work/(project-name)/(project-name)/), a change in runner environment or pathing can cause previously working strip_components values to fail [4]. 3. Flattening Alternative: If the goal is to copy the contents of a directory without including the source directory itself in the remote path, the newer flatten: true parameter is often a more reliable and intentional solution than relying on strip_components [3]. 4. Stability Issues: There have been multiple community reports of strip_components failing or behaving inconsistently in recent versions of the action, often due to changes in how the underlying tar/copy process handles pathing [4][5]. If you are experiencing unexpected behavior, it is recommended to verify the exact path structure of your source files on the runner and consider using the flatten option if applicable [4][3].
Citations:
- 1: https://github.com/appleboy/scp-action/blob/v0.1.7/README.md
- 2: docs: explain how strip_components works for english readme for now appleboy/scp-action#224
- 3: How to copy ONLY CONTENT of folder not the folder itself appleboy/scp-action#204
- 4: strip_components parameter no longer working in recent versions appleboy/scp-action#198
- 5: strip components not working when copying folder appleboy/scp-action#177
strip_components를 3으로 수정해야 합니다. source: 'server/build/libs/*.jar'는 실제로 server/build/libs/<jar> 경로를 만들기 때문에 strip_components: 2면 /home/ec2-user/app/libs/<jar>로 올라갑니다. 그러면 46-50의 find . -maxdepth 1이 새 JAR을 못 찾아 app.jar 갱신 없이 재시작됩니다.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/server-deploy.yml around lines 30 - 38, The Copy JAR to
EC2 step is stripping too few path components for the server/build/libs/*.jar
source, which leaves the uploaded JAR under an extra libs directory and prevents
the deploy flow from finding it. Update the appleboy/scp-action configuration in
the Copy JAR to EC2 job to use strip_components with the correct value so the
JAR lands directly in /home/ec2-user/app and can be picked up by the later
find-based app.jar refresh logic.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/server-ci.yml:
- Around line 1-8: The Server CI workflow currently relies on the default
GITHUB_TOKEN permissions; tighten it by adding an explicit top-level permissions
block with only the access needed for checkout and PR file-change detection.
Update the server-ci workflow near the on.pull_request configuration so the
workflow remains functional while minimizing token scope.
- Line 16: The workflow uses actions/checkout@v4 in multiple jobs without
disabling credential persistence, so update each checkout step in server-ci.yml
to set persist-credentials to false. Apply the change consistently to every
actions/checkout@v4 occurrence in the workflow, including the ones used in the
different jobs, so the default token is not retained after checkout.
In @.github/workflows/server-deploy.yml:
- Line 16: The deploy workflow is still using the mutable latest tag, so a later
push can cause EC2 to pull a different image than the one built by this run.
Update the deployment flow in the workflow that uses ECR_REGISTRY and the
related build/push/deploy steps to pass and deploy the immutable SHA tag from
the same run, and make the EC2 pull/run logic reference that SHA-tagged image
instead of latest. Ensure the image tag is propagated consistently through the
affected steps so build, push, and deploy all use the same unique tag.
- Around line 48-55: The deployment step currently starts thumbsup-server with
docker run -d but never verifies that the container is actually healthy. Update
the server-deploy workflow after the docker run step to wait for the app to come
up and check the documented /actuator/health endpoint before treating the
deployment as successful. Use the existing thumbsup-server container startup
block as the place to add the healthcheck and fail the job if the endpoint does
not return healthy.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: bdc681ac-4a33-4fb0-91b9-dfb3df3fc6ac
📒 Files selected for processing (3)
.github/workflows/server-ci.yml.github/workflows/server-deploy.ymlCLAUDE.md
✅ Files skipped from review due to trivial changes (1)
- CLAUDE.md
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/server-deploy.yml (2)
19-20: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win동시 배포 직렬화를 위한
concurrency설정을 고려하세요.
mainpush마다 이 워크플로우가 실행되므로, 짧은 간격의 연속 머지 시 두 실행이 동일 EC2에서stop/rm/run을 교차 수행해 컨테이너 상태가 꼬일 수 있습니다. 워크플로우 레벨에concurrency그룹(예:group: deploy-main,cancel-in-progress: false)을 추가해 배포를 직렬화하는 것을 권장합니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/server-deploy.yml around lines 19 - 20, The server deployment workflow currently allows overlapping runs on `main`, which can interleave `stop`/`rm`/`run` operations on the same EC2 instance. Add a workflow-level `concurrency` block in `server-deploy.yml` near `build-and-push`, using a stable group name like `deploy-main` and `cancel-in-progress: false` to serialize deployments. Keep the change at the workflow level so all jobs in this deploy pipeline share the same lock.
56-73: 🩺 Stability & Availability | 🔵 Trivial | 🏗️ Heavy lift실패 시 롤백이 없어 헬스체크 실패가 곧 서비스 다운으로 이어집니다.
기존
thumbsup-server컨테이너를 새 이미지 기동 전에stop/rm하기 때문에, 이후 헬스체크(63-73)가 실패해exit 1되면 되돌릴 이전 컨테이너가 남아있지 않습니다. 배포 실패 시 무중단이 아니라 장시간 중단으로 이어집니다.이전 이미지 태그를 보관했다가 헬스체크 실패 시 이전 컨테이너를 재기동하거나, 새 컨테이너가 정상임을 확인한 뒤에만 기존 컨테이너를 제거하는 순서로 바꾸면 실패 배포의 영향을 줄일 수 있습니다. 롤백 로직 초안을 작성해 드릴까요?
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/server-deploy.yml around lines 56 - 73, The deployment step in server-deploy workflow removes the existing thumbsup-server container before the new one passes health checks, so a failed rollout has no rollback path. Update the deployment flow to keep the previous container/image reference until the new container is verified healthy, then remove the old one, or add explicit rollback logic after the curl-based health check fails. Use the existing docker stop/rm, docker run, and health-check loop block to locate and reorder the deployment steps.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/server-deploy.yml:
- Around line 19-20: The server deployment workflow currently allows overlapping
runs on `main`, which can interleave `stop`/`rm`/`run` operations on the same
EC2 instance. Add a workflow-level `concurrency` block in `server-deploy.yml`
near `build-and-push`, using a stable group name like `deploy-main` and
`cancel-in-progress: false` to serialize deployments. Keep the change at the
workflow level so all jobs in this deploy pipeline share the same lock.
- Around line 56-73: The deployment step in server-deploy workflow removes the
existing thumbsup-server container before the new one passes health checks, so a
failed rollout has no rollback path. Update the deployment flow to keep the
previous container/image reference until the new container is verified healthy,
then remove the old one, or add explicit rollback logic after the curl-based
health check fails. Use the existing docker stop/rm, docker run, and
health-check loop block to locate and reorder the deployment steps.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 3e5cdf3c-c264-4f80-8219-a3b9ad8a1e69
📒 Files selected for processing (2)
.github/workflows/server-ci.yml.github/workflows/server-deploy.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/server-ci.yml
1 participant
무엇을 / 왜
서버 배포 인프라(AWS EC2+RDS) 세팅 진행 상황을 문서화하고, main 머지 자동배포 파이프라인 사전 준비를 완료. #47의 호스팅 결정과 MySQL 준비는 끝났지만, 자동배포 워크플로우 실전 검증과 CORS 설정은 아직 남아 있음.
변경 사항
.github/workflows/server-deploy.yml)관련 이슈
Refs #47 (배포 파이프라인 실전 검증·CORS 설정이 남아있어 아직 Closes 아님)
체크리스트
<type>(<scope>): 요약)을 따른다server/코드가 나와야 실제 검증 가능Summary by CodeRabbit
server/**변경이 있는main대상 PR에서만 서버 빌드/테스트와 시크릿 스캔이 선택적으로 실행됩니다.