-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws mutli-env deploy #730
aws mutli-env deploy #730
Conversation
WalkthroughThe pull request introduces significant modifications to the deployment workflow for Amazon ECS as defined in the The Subsequent steps have been adjusted to utilize these new environment variables. The configuration for AWS credentials now dynamically references the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
.github/workflows/deploy.yml (2)
4-11
: Excellent addition of expected variables documentation!This new section clearly explains the required repository-level variables and their expected format. It's a great improvement for maintainability and ease of setup.
Consider adding a brief example of how to set these variables in the repository settings to make it even more user-friendly.
42-66
: Excellent implementation of dynamic environment-based configuration!The new steps for setting the deployment environment and other variables greatly enhance the workflow's flexibility. The use of GitHub Environment variables ensures proper scoping, and the approach can easily accommodate new environments in the future.
To improve readability, consider using a heredoc for the multi-line environment variable setting in the "Set variables" step. For example:
- name: Set variables run: | cat << EOF >> $GITHUB_ENV APP_NAME=${{ fromJSON(vars.DEPLOY_APP_NAME)[env.DEPLOY_ENV] }} ECR_REPOSITORY=$APP_NAME-${{ env.DEPLOY_ENV }}-ecr-repo ECS_CLUSTER=$APP_NAME-${{ env.DEPLOY_ENV }}-Cluster ECS_SERVICE_DJANGO=$APP_NAME-${{ env.DEPLOY_ENV }}-Django ECS_SERVICE_CELERY=$APP_NAME-${{ env.DEPLOY_ENV }}-Celery ECS_SERVICE_CELERY_BEAT=$APP_NAME-${{ env.DEPLOY_ENV }}-CeleryBeat EOFThis approach can make the script more readable and easier to maintain.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- .github/workflows/deploy.yml (4 hunks)
🧰 Additional context used
🔇 Additional comments (5)
.github/workflows/deploy.yml (5)
18-27
: Improved workflow trigger with manual environment selection.The addition of the
workflow_dispatch
trigger with environment selection enhances flexibility for deployments. However, the commented-outpush
trigger raises a question about the intended deployment strategy.Could you clarify the intended deployment strategy? If automatic deployments to production are still desired, consider using a conditional statement to trigger the workflow on push to the main branch with the production environment. For example:
on: workflow_dispatch: inputs: environment: description: "Deploy environment" required: true type: choice options: - dev - prod push: branches: - mainThen, in the "Set Deploy Env" step, you can add:
elif [[ "${{ github.event_name }}" == "push" && "${{ github.ref }}" == "refs/heads/main" ]]; then DEPLOY_ENV="prod"This would maintain automatic production deployments while allowing manual triggers for both environments.
70-72
: Good use of environment-specific AWS credentials!The modification to use environment-specific variables for
role-to-assume
andaws-region
is a great improvement. This allows for different AWS accounts and regions per environment, enhancing the workflow's flexibility.To ensure that the AWS account and region are correctly set for each environment, consider adding a verification step after the AWS credentials configuration:
- name: Verify AWS configuration run: | echo "Configured AWS Account: $(aws sts get-caller-identity --query Account --output text)" echo "Configured AWS Region: ${{ env.AWS_REGION }}"This step will print the configured AWS account and region, allowing for easy verification during workflow runs.
105-105
: Correct implementation of environment-specific task definition family.The modification to use
env.APP_NAME
andenv.DEPLOY_ENV
in thetask-definition-family
is correct and consistent with the previously set variables. This change allows for different task definition families per environment, which is essential for multi-environment deployments.
121-121
: Consistent implementation of environment-specific task definition family for Celery worker.The modification to use
env.APP_NAME
andenv.DEPLOY_ENV
in thetask-definition-family
for the Celery worker is correct and consistent with the previous changes. This ensures that the Celery worker task definition is properly segregated per environment.
129-129
: Consistent implementation of environment-specific task definition family for Celery beat.The modification to use
env.APP_NAME
andenv.DEPLOY_ENV
in thetask-definition-family
for the Celery beat is correct and consistent with the previous changes. This completes the set of changes required for environment-specific task definitions across all services.These changes collectively ensure that all ECS task definitions (Django web, Celery worker, and Celery beat) are properly segregated per environment. This is crucial for maintaining separate configurations and deployments for different environments (e.g., dev and prod). The consistent use of
env.APP_NAME
andenv.DEPLOY_ENV
across all services reduces the chance of errors and improves maintainability.
Codecov ReportAll modified and coverable lines are covered by tests ✅ Additional details and impacted files📢 Thoughts on this report? Let us know! |
Description
Update the deploy action to support multiple environments (currently 'dev' and 'prod')