-
Notifications
You must be signed in to change notification settings - Fork 187
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
Replace Chef with ECS Deployment #8314
Conversation
1dc24b2
to
0c54a5e
Compare
a4ea963
to
96c7cca
Compare
93a00c2
to
2430db3
Compare
So a staging server does come up successfully with Sidekiq and PMA. There is still one issue with a webpacker dependency when building assets though: |
Here is an explanation of my proposed way of building and deploying images that I implemented in this (and #8338) PR: |
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.
Any reason why you paste the bucket into a variable before accessing it?
All use-cases in your most recent commit can be boiled down to regulations_bucket.object(...)
directly
I did it because using @@s3 means we don't need to instantiate the bucket every time. I think I have a neater solution though |
Sorry to say but your most recent commit changes absolutely nothing. Passing the parameter as a default argument simply means Rails will call it for you every time that a parameter hasn't been supplied otherwise. |
Ah, now things are getting more interesting 😎 |
70bcc9e
to
4b7c832
Compare
826e982
to
7eb8199
Compare
After testing the docker-compose landscape, we have decided it makes more sense to go straight to ECS, as updating the images by ourselves is much more of a hassle
TODO: