-
Notifications
You must be signed in to change notification settings - Fork 32
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
Cloudformation templates to deploy feature branch to crowd-test #758
Conversation
…rvices, task definition named with feature branch
d53bbf0
to
2f6a2fd
Compare
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.
This generally looks good to me. The one question I had is whether we should be taking the time now to convert the hard-coded names for security groups, VPC IDs, etc. into output references or not. I'm slightly hesitant to do so since that adds more exposure to CloudFormation bugs but it would reduce the number of updates.
I was sorta thinking that too. Like, what if we decide we want to push feature branches to crowd-dev or something, what would the changes need to be, what should be parameterized, etc. But, I figured I'd address that if / when we decide to do this sort of thing again in a different VPC. |
I wish I didn't have to make a special copy of the elasticache template for this, but I couldn't figure out how to pass the list of subnet IDs as a string as required. Any thoughts on that?
I'm also not sure if the parameter "ConcordiaBranch" should actually be "DockerTag" since that's what it is.
I'm making the assumption that Jenkins (or something) will build and publish feature branches to our container repository with the docker tag = branch name.Jenkins is doing this already