feat: GitHub Actions CI/CD#6
Open
jhlarry1109 wants to merge 1 commit into
Open
Conversation
📝 WalkthroughWalkthrough
ChangesECS Auth 서비스 배포 워크플로우
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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: 5
🧹 Nitpick comments (5)
.github/workflows/deploy.yml (5)
45-45: ⚡ Quick winProvenance 비활성화를 재고하세요.
--provenance=false옵션은 이미지의 출처 정보를 제거합니다. Provenance는 소프트웨어 공급망 보안을 위한 중요한 메타데이터를 제공하므로, 특별한 이유가 없다면 활성화하는 것이 좋습니다.일부 ECR 구성에서 multi-platform manifest 문제로 인해 비활성화가 필요한 경우도 있지만, 가능하면 ECR 설정을 조정하여 provenance를 유지하는 것을 권장합니다.
🔒 제안하는 수정 방안
docker buildx build \ --platform linux/amd64 \ - --provenance=false \ -t $IMAGE_URI \ . \ --push만약 ECR과의 호환성 문제가 있다면,
--provenance=true를 명시적으로 설정하고 ECR 레포지토리 설정을 확인하세요.🤖 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/deploy.yml at line 45, The `--provenance=false` flag in the Docker build command disables provenance metadata, which is critical for software supply chain security and provides important information about the image's origin. Remove or change this flag to `--provenance=true` to enable provenance tracking, and if there are multi-platform manifest compatibility issues with ECR, address those by adjusting the ECR repository configuration rather than disabling provenance security features.
39-48: ⚡ Quick win빌드 캐시를 활용하여 빌드 시간을 단축하세요.
현재 빌드 과정에서 캐시를 활용하지 않아 매번 전체 레이어를 다시 빌드합니다. GitHub Actions 캐시나 ECR을 캐시 백엔드로 사용하면 빌드 시간을 크게 단축할 수 있습니다.
⚡ 제안하는 수정 방안
- name: Build and push Docker image run: | IMAGE_URI=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPOSITORY}:${IMAGE_TAG} docker buildx build \ --platform linux/amd64 \ --provenance=false \ + --cache-from type=registry,ref=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPOSITORY}:buildcache \ + --cache-to type=registry,ref=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPOSITORY}:buildcache,mode=max \ -t $IMAGE_URI \ . \ --push🤖 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/deploy.yml around lines 39 - 48, The docker buildx build command for building and pushing the Docker image does not utilize caching, causing full layer rebuilds on each invocation. Add cache configuration to the docker buildx build step by including --cache-from and --cache-to flags that leverage either GitHub Actions built-in cache (type=gha) or ECR as the cache backend (type=registry). This will significantly reduce build time by reusing previously built layers across workflow runs.
11-11: ⚡ Quick winAWS 계정 ID를 시크릿으로 관리하세요.
AWS 계정 ID가 워크플로우에 하드코딩되어 있습니다. Public 저장소에서는 이러한 정보 노출이 보안 위험이 될 수 있습니다. GitHub Secrets에 저장하여 관리하는 것을 권장합니다.
🔒 제안하는 수정 방안
- AWS_ACCOUNT_ID: 727452759104 + AWS_ACCOUNT_ID: ${{ secrets.AWS_ACCOUNT_ID }}그리고 GitHub 저장소 Settings > Secrets and variables > Actions에서
AWS_ACCOUNT_ID시크릿을 추가하세요.🤖 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/deploy.yml at line 11, The AWS_ACCOUNT_ID environment variable is hardcoded with the actual account ID value, which is a security risk in a public repository. Replace the hardcoded account ID value with a reference to a GitHub secret using the appropriate GitHub Actions secret syntax. This will ensure the sensitive account ID is stored securely in the repository's Secrets settings rather than being exposed in the workflow file.
26-31: 🏗️ Heavy liftOIDC를 사용한 AWS 인증을 고려하세요.
현재 장기 AWS 액세스 키를 사용하고 있습니다. GitHub Actions의 OIDC(OpenID Connect)를 사용하면 장기 자격증명을 저장할 필요 없이 임시 자격증명을 안전하게 얻을 수 있습니다.
🔒 제안하는 수정 방안 (OIDC 사용)
AWS IAM에서 OIDC 공급자를 설정한 후:
- name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v5 with: aws-region: ${{ env.AWS_REGION }} - aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} - aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} + role-to-assume: arn:aws:iam::${{ env.AWS_ACCOUNT_ID }}:role/GitHubActionsRole + role-session-name: GitHubActions-${{ github.run_id }}그리고 permissions에
id-token: write추가가 필요합니다.🤖 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/deploy.yml around lines 26 - 31, The deploy workflow is currently using long-term AWS credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY secrets) which poses a security risk. Replace this approach by configuring OIDC (OpenID Connect) authentication in the configure-aws-credentials action. Remove the aws-access-key-id and aws-secret-access-key inputs from the step, and instead add a role-to-assume parameter that references an AWS IAM role configured with an OIDC trust relationship for GitHub. Additionally, add id-token: write permission to the job's permissions block to allow GitHub to generate OIDC tokens for AWS authentication.
58-63: ⚡ Quick win배포 실패 시 알림 메커니즘을 추가하세요.
현재 워크플로우에는 배포 성공 또는 실패 시 알림 메커니즘이 없습니다. 프로덕션 배포의 경우 팀에 즉시 알리는 것이 중요합니다.
📢 제안하는 수정 방안 (Slack 알림 예시)
- name: Wait for ECS service stable run: | aws ecs wait services-stable \ --cluster $ECS_CLUSTER \ --services $ECS_SERVICE \ --region $AWS_REGION + + - name: Notify deployment success + if: success() + uses: slackapi/slack-github-action@v1 + with: + payload: | + { + "text": "✅ Auth 서비스 배포 성공: ${{ github.sha }}" + } + env: + SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} + + - name: Notify deployment failure + if: failure() + uses: slackapi/slack-github-action@v1 + with: + payload: | + { + "text": "❌ Auth 서비스 배포 실패: ${{ github.sha }}" + } + env: + SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}🤖 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/deploy.yml around lines 58 - 63, The deployment workflow is missing notification mechanisms to alert the team when deployments fail. After the "Wait for ECS service stable" step in the workflow, add a new step that uses a condition to execute only if the deployment fails (using if: failure() or similar conditional syntax). This failure notification step should send an alert to your notification service (such as Slack, email, or your chosen alerting system) with relevant details about the failed deployment, including the cluster name, service name, and any error information from the previous steps. Optionally, also add a success notification step to confirm successful deployments to the team.
🤖 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/deploy.yml:
- Line 15: The IMAGE_TAG variable in the deploy.yml workflow is hardcoded to
'latest', which prevents proper version tracking and rollback capabilities.
Replace the hardcoded 'latest' value with a dynamic identifier such as the Git
commit SHA (accessible via github.sha context) or a combination of timestamp and
commit SHA. This will ensure each deployment is uniquely identifiable and
enables tracking of which code version is deployed.
- Around line 23-24: The actions/checkout@v4 action is configured with default
settings that persist Git credentials, which could expose them in subsequent
workflow steps. Add the persist-credentials parameter set to false in the
actions/checkout step to disable credential persistence and prevent unintended
credential exposure.
- Around line 17-21: The workflow lacks explicit permission declarations,
relying on default permissions which violates the principle of least privilege.
Add a `permissions` block to the deploy job with only the minimum required
permissions needed for the build and deployment tasks. Specify each required
permission explicitly (such as contents, packages, id-token, etc.) with
appropriate access levels (read, write, or none) based on what the job actually
needs to accomplish.
- Around line 50-56: The current ECS deployment step only uses
--force-new-deployment without explicitly updating the task definition to
reference the new image, which is unreliable when using dynamic image tags.
Replace the aws ecs update-service command with the
aws-actions/amazon-ecs-deploy-task-definition GitHub Action, which will properly
update the task definition with the new image tag before deploying. Ensure you
reference the correct task definition name and container name (which need to
match your actual ECS configuration) in the action configuration, along with the
image parameter that includes the new IMAGE_TAG value.
- Line 24: Pin all GitHub Actions in .github/workflows/deploy.yml to specific
commit hashes instead of version tags to prevent supply chain attacks. At line
24, replace actions/checkout@v4 with actions/checkout@34e1148. At line 27,
replace aws-actions/configure-aws-credentials@v5 with
aws-actions/configure-aws-credentials@cabfdba. At line 34, replace
aws-actions/amazon-ecr-login@v2 with aws-actions/amazon-ecr-login@d539f09. At
line 37, replace docker/setup-buildx-action@v3 with
docker/setup-buildx-action@8d2750c. This ensures immutable action references
that cannot be altered by tag reassignment.
---
Nitpick comments:
In @.github/workflows/deploy.yml:
- Line 45: The `--provenance=false` flag in the Docker build command disables
provenance metadata, which is critical for software supply chain security and
provides important information about the image's origin. Remove or change this
flag to `--provenance=true` to enable provenance tracking, and if there are
multi-platform manifest compatibility issues with ECR, address those by
adjusting the ECR repository configuration rather than disabling provenance
security features.
- Around line 39-48: The docker buildx build command for building and pushing
the Docker image does not utilize caching, causing full layer rebuilds on each
invocation. Add cache configuration to the docker buildx build step by including
--cache-from and --cache-to flags that leverage either GitHub Actions built-in
cache (type=gha) or ECR as the cache backend (type=registry). This will
significantly reduce build time by reusing previously built layers across
workflow runs.
- Line 11: The AWS_ACCOUNT_ID environment variable is hardcoded with the actual
account ID value, which is a security risk in a public repository. Replace the
hardcoded account ID value with a reference to a GitHub secret using the
appropriate GitHub Actions secret syntax. This will ensure the sensitive account
ID is stored securely in the repository's Secrets settings rather than being
exposed in the workflow file.
- Around line 26-31: The deploy workflow is currently using long-term AWS
credentials (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY secrets) which poses a
security risk. Replace this approach by configuring OIDC (OpenID Connect)
authentication in the configure-aws-credentials action. Remove the
aws-access-key-id and aws-secret-access-key inputs from the step, and instead
add a role-to-assume parameter that references an AWS IAM role configured with
an OIDC trust relationship for GitHub. Additionally, add id-token: write
permission to the job's permissions block to allow GitHub to generate OIDC
tokens for AWS authentication.
- Around line 58-63: The deployment workflow is missing notification mechanisms
to alert the team when deployments fail. After the "Wait for ECS service stable"
step in the workflow, add a new step that uses a condition to execute only if
the deployment fails (using if: failure() or similar conditional syntax). This
failure notification step should send an alert to your notification service
(such as Slack, email, or your chosen alerting system) with relevant details
about the failed deployment, including the cluster name, service name, and any
error information from the previous steps. Optionally, also add a success
notification step to confirm successful deployments to the team.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ac4a9250-49df-4d7e-8802-7acf6fed89bb
📒 Files selected for processing (1)
.github/workflows/deploy.yml
| ECR_REPOSITORY: momentlit/auth | ||
| ECS_CLUSTER: default | ||
| ECS_SERVICE: momentlit-auth-service | ||
| IMAGE_TAG: latest |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
이미지 태그에 동적 값 사용을 권장합니다.
이미지 태그가 latest로 고정되어 있어 다음 문제가 발생합니다:
- 특정 버전으로 롤백이 어려움
- 어떤 코드 버전이 배포되었는지 추적 불가
- 이미지 캐싱 문제 발생 가능
Git 커밋 SHA 또는 타임스탬프를 사용하여 각 배포를 고유하게 식별할 수 있도록 개선하는 것이 좋습니다.
♻️ 제안하는 수정 방안
- IMAGE_TAG: latest
+ IMAGE_TAG: ${{ github.sha }}또는 날짜와 SHA를 조합:
- IMAGE_TAG: latest
+ IMAGE_TAG: ${{ github.run_number }}-${{ github.sha }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| IMAGE_TAG: latest | |
| IMAGE_TAG: ${{ github.sha }} |
🤖 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/deploy.yml at line 15, The IMAGE_TAG variable in the
deploy.yml workflow is hardcoded to 'latest', which prevents proper version
tracking and rollback capabilities. Replace the hardcoded 'latest' value with a
dynamic identifier such as the Git commit SHA (accessible via github.sha
context) or a combination of timestamp and commit SHA. This will ensure each
deployment is uniquely identifiable and enables tracking of which code version
is deployed.
Comment on lines
+17
to
+21
| jobs: | ||
| deploy: | ||
| name: Build and Deploy Auth | ||
| runs-on: ubuntu-latest | ||
|
|
There was a problem hiding this comment.
최소 권한 원칙을 적용하여 명시적인 permissions를 설정하세요.
워크플로우에 명시적인 permissions 블록이 없어 기본 권한을 사용하고 있습니다. 보안 모범 사례에 따라 필요한 최소 권한만 부여해야 합니다.
🔒 제안하는 수정 방안
jobs:
deploy:
name: Build and Deploy Auth
runs-on: ubuntu-latest
+ permissions:
+ contents: read
+ id-token: write # OIDC를 사용하는 경우📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| jobs: | |
| deploy: | |
| name: Build and Deploy Auth | |
| runs-on: ubuntu-latest | |
| jobs: | |
| deploy: | |
| name: Build and Deploy Auth | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: read | |
| id-token: write # OIDC를 사용하는 경우 |
🤖 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/deploy.yml around lines 17 - 21, The workflow lacks
explicit permission declarations, relying on default permissions which violates
the principle of least privilege. Add a `permissions` block to the deploy job
with only the minimum required permissions needed for the build and deployment
tasks. Specify each required permission explicitly (such as contents, packages,
id-token, etc.) with appropriate access levels (read, write, or none) based on
what the job actually needs to accomplish.
Source: Linters/SAST tools
Comment on lines
+23
to
+24
| - name: Checkout source code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
자격증명 유지를 비활성화하세요.
actions/checkout이 기본적으로 Git 자격증명을 유지하도록 설정되어 있어, 이후 단계에서 의도치 않게 자격증명이 노출될 수 있습니다.
🔒 제안하는 수정 방안
- name: Checkout source code
uses: actions/checkout@v4
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - name: Checkout source code | |
| uses: actions/checkout@v4 | |
| - name: Checkout source code | |
| uses: actions/checkout@v4 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 23-24: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 24-24: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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/deploy.yml around lines 23 - 24, The actions/checkout@v4
action is configured with default settings that persist Git credentials, which
could expose them in subsequent workflow steps. Add the persist-credentials
parameter set to false in the actions/checkout step to disable credential
persistence and prevent unintended credential exposure.
Source: Linters/SAST tools
|
|
||
| steps: | ||
| - name: Checkout source code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: 각 액션의 태그에 해당하는 커밋 해시 조회
echo "=== actions/checkout@v4 ==="
gh api repos/actions/checkout/git/ref/tags/v4 --jq '.object.sha'
echo "=== aws-actions/configure-aws-credentials@v5 ==="
gh api repos/aws-actions/configure-aws-credentials/git/ref/tags/v5 --jq '.object.sha'
echo "=== aws-actions/amazon-ecr-login@v2 ==="
gh api repos/aws-actions/amazon-ecr-login/git/ref/tags/v2 --jq '.object.sha'
echo "=== docker/setup-buildx-action@v3 ==="
gh api repos/docker/setup-buildx-action/git/ref/tags/v3 --jq '.object.sha'Repository: MomentLit/Auth
Length of output: 377
🏁 Script executed:
cat .github/workflows/deploy.ymlRepository: MomentLit/Auth
Length of output: 1697
모든 GitHub Actions를 커밋 해시로 고정하세요.
워크플로우의 모든 액션이 버전 태그로만 참조되어 있어 공급망 공격에 취약합니다. 태그는 이동 가능하지만 커밋 해시는 불변이므로, 보안 모범 사례에 따라 각 액션을 특정 커밋 해시로 고정해야 합니다.
다음 액션들을 수정하세요:
actions/checkout@v4→actions/checkout@34e1148aws-actions/configure-aws-credentials@v5→aws-actions/configure-aws-credentials@cabfdbaaws-actions/amazon-ecr-login@v2→aws-actions/amazon-ecr-login@d539f09docker/setup-buildx-action@v3→docker/setup-buildx-action@8d2750c
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 23-24: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 24-24: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
📍 Affects 1 file
.github/workflows/deploy.yml#L24-L24(this comment).github/workflows/deploy.yml#L27-L27.github/workflows/deploy.yml#L34-L34.github/workflows/deploy.yml#L37-L37
🤖 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/deploy.yml at line 24, Pin all GitHub Actions in
.github/workflows/deploy.yml to specific commit hashes instead of version tags
to prevent supply chain attacks. At line 24, replace actions/checkout@v4 with
actions/checkout@34e1148. At line 27, replace
aws-actions/configure-aws-credentials@v5 with
aws-actions/configure-aws-credentials@cabfdba. At line 34, replace
aws-actions/amazon-ecr-login@v2 with aws-actions/amazon-ecr-login@d539f09. At
line 37, replace docker/setup-buildx-action@v3 with
docker/setup-buildx-action@8d2750c. This ensures immutable action references
that cannot be altered by tag reassignment.
Source: Linters/SAST tools
Comment on lines
+50
to
+56
| - name: Force new ECS deployment | ||
| run: | | ||
| aws ecs update-service \ | ||
| --cluster $ECS_CLUSTER \ | ||
| --service $ECS_SERVICE \ | ||
| --force-new-deployment \ | ||
| --region $AWS_REGION |
There was a problem hiding this comment.
Task definition을 업데이트하는 방식으로 개선하세요.
현재 --force-new-deployment만 사용하고 있는데, 이는 기존 task definition을 재배포할 뿐 새 이미지 태그를 반영하지 않습니다. IMAGE_TAG가 latest이므로 작동할 수도 있지만, 명시적으로 task definition을 업데이트하여 새 이미지를 참조하도록 하는 것이 더 안전하고 예측 가능합니다.
특히 이미지 태그를 동적으로 변경하는 경우 (예: Git SHA 사용) task definition 업데이트가 필수입니다.
🔧 제안하는 수정 방안
aws-actions/amazon-ecs-deploy-task-definition 액션 사용:
+ - name: Download task definition
+ run: |
+ aws ecs describe-task-definition \
+ --task-definition momentlit-auth-task \
+ --region ${{ env.AWS_REGION }} \
+ --query 'taskDefinition' > task-definition.json
+
+ - name: Fill in the new image ID in the Amazon ECS task definition
+ id: task-def
+ uses: aws-actions/amazon-ecs-render-task-definition@v1
+ with:
+ task-definition: task-definition.json
+ container-name: auth
+ image: ${{ env.AWS_ACCOUNT_ID }}.dkr.ecr.${{ env.AWS_REGION }}.amazonaws.com/${{ env.ECR_REPOSITORY }}:${{ env.IMAGE_TAG }}
+
+ - name: Deploy Amazon ECS task definition
+ uses: aws-actions/amazon-ecs-deploy-task-definition@v1
+ with:
+ task-definition: ${{ steps.task-def.outputs.task-definition }}
+ service: ${{ env.ECS_SERVICE }}
+ cluster: ${{ env.ECS_CLUSTER }}
+ wait-for-service-stability: true
-
- - name: Force new ECS deployment
- run: |
- aws ecs update-service \
- --cluster $ECS_CLUSTER \
- --service $ECS_SERVICE \
- --force-new-deployment \
- --region $AWS_REGION
-
- - name: Wait for ECS service stable
- run: |
- aws ecs wait services-stable \
- --cluster $ECS_CLUSTER \
- --services $ECS_SERVICE \
- --region $AWS_REGION참고: task definition 이름과 컨테이너 이름을 실제 값으로 조정해야 합니다.
🤖 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/deploy.yml around lines 50 - 56, The current ECS
deployment step only uses --force-new-deployment without explicitly updating the
task definition to reference the new image, which is unreliable when using
dynamic image tags. Replace the aws ecs update-service command with the
aws-actions/amazon-ecs-deploy-task-definition GitHub Action, which will properly
update the task definition with the new image tag before deploying. Ensure you
reference the correct task definition name and container name (which need to
match your actual ECS configuration) in the action configuration, along with the
image parameter that includes the new IMAGE_TAG value.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#️⃣ 연관된 이슈
📝 작업 내용
💻 스크린샷 (선택)
💬 리뷰 요청 사항 (선택)
Summary by CodeRabbit
릴리스 노트