-
-
Notifications
You must be signed in to change notification settings - Fork 148
Making Deploy Stage Optional #116
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
Conversation
/terratest |
@pcartas Hi, can you update the pr so that it passes the tests? otherwise, it is likely to be closed due to staleness. |
💥 This pull request now has conflicts. Could you fix it @pcartas? 🙏 |
This PR was closed due to inactivity and merge conflicts. 😭 |
Caution Review failedThe pull request is closed. 📝 WalkthroughWalkthroughA new boolean input, Changes
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
what
I create a new variable called deploy_stage_enabled, and then make dynamic the deploy stage of aws_codepipeline bitbucket and aws_codepipeline default
why
It allows you to create images without deploying them, which could be useful for creating dummy images. However, there's a catch-22 situation: when you create a service, you need an initial image that at least responds to the health path. But first, you need to run a pipeline, and the pipeline is not created before the service. Moreover, ECS (specially if you are using EC2) tends to cache images/references to those images, and if you always use the image with the 'latest' tag, you risk using an old image. To avoid this, it's good practice to tag your image twice (with 'latest' and a random tag). The idea behind this was to create a dummy image, pull it from my service module, and then push it with the correct tags to the ECR of the service (thereby making it the base image of the service). Then I would define my container as follows: