-
Notifications
You must be signed in to change notification settings - Fork 4
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
Fix: Production docker image built without test gems #334
Conversation
These changes worked well for CAEW and we should get this merged in! |
I'd like to get this in, but the tests are failing at the mo |
I've checked with Dragon and I'm going to try and move this along. |
5ab524e
to
e90cc67
Compare
@pezholio back in business with a green test suite 👍 |
ec897be
to
5923dca
Compare
@erbridge I completely forgot about this! I've actioned your feedback now. |
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.
Looks sensible to me. Minor commit message issue, but otherwise 👍.
c453b42
to
a10301d
Compare
LGTM, I can't approve as the creator, but @tabh feel free to approve on my behalf if you're happy with it :) |
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.
Approving on behalf of Dragon who's the original author and therefore can't :)
`bundle config set with $BUNDLE_GEM_GROUPS` wasn't doing what we thought in the production context. It'd work out to be `bundle config set with production` which would bundle everything, rather than only production groups. I'm not sure where this assumption came from. 'default' also doesn't work. As the first step of a bit of a refactoring of the Dockerfile, we cement the assurance that by default the dockerfile _only_ bundles production gems. We remove the way the build_arg `RAILS_ENV` was used to accomodate being built for production, development and test. This hopefully makes it much clearer. (I've also set NODE_ENV to follow the same path as RAILS_ENV -- Dragon)
Instead of passing `RAILS_ENV` as a build argument to the dockerfile to figure out what should be bundled. We switch to using `--target` to target a specific docker build stage that hardcodes the `RAILS_ENV` so it can't have an unexpected value. We now have a stage for production, development and test. Each explicitly installs gems for the right group.
When building the docker image in production with script/docker/update we get a new error: ``` > [production 21/23] RUN if [ "production" = "production" ]; then SECRET_KEY_BASE="secret" bundle exec rake assets:precompile; fi: 43 3.045 Yarn executable was not detected in the system. 43 3.045 Download Yarn at https://yarnpkg.com/en/docs/install 43 3.326 Yarn executable was not detected in the system. 43 3.326 Download Yarn at https://yarnpkg.com/en/docs/install 43 3.668 rake aborted! 43 3.668 Uglifier::Error: Unexpected token: keyword (const). To use ES6 syntax, harmony mode must be enabled with Uglifier.new(:harmony => true). … 43 3.668 11663 /** 43 3.668 11664 * ------------------------------------------------------------------------ 43 3.668 11665 * Constants 43 3.668 11666 * ------------------------------------------------------------------------ 43 3.668 11667 */ 43 3.668 => const elementMap = new Map(); ``` We follow the instruction to use `Uglifier.new(:harmony => true)` and sure enought the error is silenced.
When starting the application with RAILS_ENV=production mode and we run `rake` we get an error that explains we don't have standard installed. This is correct as out gemfile specifies that we only install standard in the dev and test environments. This change only tries to load the standard rake task when in the dev or test environment. Other take tasks such as `rails db:prepare` can still run in any environment as normal.
4fbec67
to
70b6b2b
Compare
Been trying to get the tests passing on this to no avail, sorry! |
Converted to draft because this is no longer fit to be published, but someone might want to build on this work in future. Also it'll silence the notifications I get for it... |
Given the state and age of this work, I am closing this PR. |
Backport of https://github.com/citizensadvice/corporate-api/pull/55
The CA Corporate API is headless, so it doesn't use node, which means it's likely that this doesn't yet correctly handle node modules.
Changes in this PR
Before this change our Dockerfile wasn't correctly creating Docker images. It was bundling gems from the
test
group despite expectingRAILS_ENV
to be set asproduction
by default. We don't want to be deploying live artefacts that have test dependencies and tooling installed. They are bigger and increase the surface area for complexity and attacks.The meat of this change is centered around the Dockerfile. Instead of using
RAILS_ENV
to try and let the user convey what gems they expected, we switch to creating more explicit docker build stages and select them with thetarget
field instead.Testing
DOCKER=1 script/test
should still run all the tests (and have the test gems to do so)DOCKER=1 script/server
should still start up a local development server and be accesible at localhost:3000If you want to test this in production too you can temporarily copy this into your app directory, into a file called
docker-compose.production.yml
. Once there you can rundocker-compose -f docker-compose.production.yml up
to check it boots in the right environment and watch that the right gems were installed: