Dockerfile: Changes to make Yarn work reliably#86
Conversation
* Move Yarn-managed packages to a specific directory, the same way we did in BerkeleyLibrary/UCBEARS#17. This makes it easier to handle. * Add Yarn binstubs to the available PATH. * Copy the lock file into the app directory, which is required for the cssbundling task to determine we are using Yarn. Otherwise we will have this error: cssbundling-rails: No suitable tool found for installing JavaScript dependencies * Switch to headless JRE to lower attack surface and use less resources. Ref: AP-779
anarchivist
left a comment
anarchivist
left a comment
There was a problem hiding this comment.
generally r+; one minor question.
| # Use Yarn via Corepack to avoids using reops and GPG keys | ||
| RUN corepack enable \ | ||
| && corepack prepare yarn@stable --activate \ | ||
| && corepack prepare yarn@1.22.22 --activate \ |
There was a problem hiding this comment.
is this effectively downgrading yarn from our past images?
There was a problem hiding this comment.
It installed a stable yarn that was never used, because the package specified 1.22.22. This just ensures it downloads that version the first time, so it doesn't waste the time of fetching a useless one.
There was a problem hiding this comment.
+1 I made the same change in my refactoring of Yuchai's PR.
| g++ \ | ||
| make | ||
|
|
||
| RUN mkdir -p /usr/local/yarn && chown $APP_USER:$APP_USER /usr/local/yarn |
There was a problem hiding this comment.
Nit: Just do all of this when setting up the application user at the top of the Dockerfile:
install -d -o $APP_USER -g $APP_USER path1 path2 …| # Use Yarn via Corepack to avoids using reops and GPG keys | ||
| RUN corepack enable \ | ||
| && corepack prepare yarn@stable --activate \ | ||
| && corepack prepare yarn@1.22.22 --activate \ |
There was a problem hiding this comment.
+1 I made the same change in my refactoring of Yuchai's PR.
| COPY --from=development --chown=geodata /opt/app /opt/app | ||
| COPY --from=development --chown=geodata /usr/local/bundle /usr/local/bundle | ||
| COPY --from=development --chown=geodata /usr/local/yarn /usr/local/yarn | ||
| RUN cp /usr/local/yarn/yarn.lock /opt/app/ |
There was a problem hiding this comment.
What's the reasoning behind not committing yarn.lock?
There was a problem hiding this comment.
I wasn't sure if this was something GeoData-specific. If we can commit it instead, that'd be even better.
| COPY --from=development --chown=geodata /usr/local/bundle /usr/local/bundle | ||
| COPY --from=development --chown=geodata /usr/local/yarn /usr/local/yarn | ||
| RUN cp /usr/local/yarn/yarn.lock /opt/app/ | ||
| RUN ln -s /usr/local/yarn/node_modules /opt/app/node_modules |
There was a problem hiding this comment.
Is all this pageantry with installing to /usr/local/yarn/… just to avoid conflicts with the bind mount when developing locally?
There was a problem hiding this comment.
I believe the idea was to keep it separate from /opt/app so that it can be copied entirely (since some files are written to the base directory outside of node_modules), and to prevent the vendor files from clogging up the source tree. This level of clean separation isn't necessary, just something I thought I'd do while I was here (and to match UCBEARS).
|
Superseded by #90. |
3 participants
Move Yarn-managed packages to a specific directory, the same way we did in Added NODE_PATH to Dockerfile and configure yarn build in prod target UCBEARS#17. This makes it easier to handle.
Add Yarn binstubs to the available PATH.
Copy the lock file into the app directory, which is required for the cssbundling task to determine we are using Yarn. Otherwise we will have this error:
cssbundling-rails: No suitable tool found for installing JavaScript dependencies
Switch to headless JRE to lower attack surface and use less resources.
Ref: AP-779