-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
build: restructure "vendor" directories to improve build #32835
Conversation
5a94bf3
to
9e4d32b
Compare
@feanil Looks like I'll need to merge this one last assets PR in order for the optimized Tutor image build to work. The change is here kinda nuanced, and I'm not sure I did the best job describing it. Review if you can; if not, I can come back and rework the description once I'm back from PTO. |
Eh, nevermind, tests are failing. Putting this back in draft state for now. |
9e4d32b
to
34583aa
Compare
fd9111f
to
389b778
Compare
3ac4c5c
to
403913b
Compare
39e9926
to
972f26c
Compare
972f26c
to
9adcccd
Compare
Sass compilation includes the LMS's "vendored-in" CSS libraries at lms/static/css/vendor as a source, and output CSS is written to the parent directory, lms/static/css. This violates the constraint that source directories cannot be written to while they are bind-mounted. To resolve the issue, we merge the contents of lms/static/css/vendor into common/static/css/vendor. (The directory common/static/css only contains sources: no CSS is outputted there.) Now, common/static/css only contains sources for the Sass build, and lms/static/css is only used for output. More details: openedx#32835 Part of: https://github.com/openedx/wg-developer-experience/issues/166
…ies/[js|css] To support our old RequireJS-based frontends, a post-install hook on npm clean-install copies certain JS & CSS modules into common/static/common/[js|css]/vendor. However, the copied modules' ancestor directory, common/static/common, is a source for the Webpack build that we need to bind-mount. This violates the constraint that we must not bind-mount items that were previously modified by the build. To resolve the issue, we relocate common/static/common/[js|css]/vendor to new directories, common/static/node_copies/[js|css]. We provide a symlink from the original location to a new location. Now, common/static/common and common/static/node_copies can both be used as inputs to the Webpack build, but the latter will not be clobbered when we bind-mount the former. Furthermore, the new directory name ("node_copies") is more illustrative than the old one ("vendor"). (Note: I originally attempted to make this change without the symlink--I updated all references to the old path to the new path. I struggled for several hours to get tests passing for JS using RequireJS, and concluded that I don't understand our RequireJS setup well enough to safely make that change.) More details: openedx#32835 Part of: https://github.com/openedx/wg-developer-experience/issues/166
9adcccd
to
8ec506c
Compare
Thanks for the pull request, @kdmccormick! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. Once you've signed the CLA, please allow 1 business day for it to be processed. After this time, you can re-run the CLA check by editing the PR title. If the problem persists, you can tag the |
I've realized that I can use |
@kdmccormick Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future. |
1 similar comment
@kdmccormick Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future. |
Sass compilation includes the LMS's "vendored-in" CSS libraries at lms/static/css/vendor as a source, and output CSS is written to the parent directory, lms/static/css. This violates the constraint that source directories cannot be written to while they are bind-mounted. To resolve the issue, we merge the contents of lms/static/css/vendor into common/static/css/vendor. (The directory common/static/css only contains sources: no CSS is outputted there.) Now, common/static/css only contains sources for the Sass build, and lms/static/css is only used for output. More details: openedx#32835 Part of: https://github.com/openedx/wg-developer-experience/issues/166
Context
(Part of: openedx/wg-devops#21)
Our overall goal is to minimize Docker image rebuild time while also maintaining Docker image correctness for edx-platform developers.
As of recently, Tutor lets edx-platform developers use their local edx-platform repository as input into the Docker image build. Before this, developers would either have to:
Tutor achieves this improvement by bind-mounting several source items (files or directories) from edx-platform into the Docker build context during each build step. When choosing which source items to bind-mount at each build step, we have several constraints:
For example, look at the build step that installs NPM packages:
npm clean-install
.npm clean-install
.npm clean-install
.npm clean-install
. Note that runningnpm install
would fail because it could modify package-lock.json.The problem is that the current structure of edx-platform, particularly the "vendor" folders, makes it impossible to follow these constraints when building static assets. Tutor currently works around this by sacrificing some correctness: static assets sources are not bind-mounted, so local changes to static assets will not be reflected in the image build.
This PR fixes the structure of edx-platform vendor folders. This will benefit Tutor users, but it will generally benefit anyone who is trying to write a finely-tuned Dockerfile for edx-platform.
Change Descriptions
Changes Visualized
Change 1: build: lms/static/css/vendor/* -> common/static/css/vendor
Sass compilation includes the LMS's "vendored-in" CSS libraries at
lms/static/css/vendor
as a source, and output CSS is written to the parent directory,lms/static/css
. This violates the constraint that source directories cannot be written to while they are bind-mounted.To resolve the issue, we merge the contents of
lms/static/css/vendor
intocommon/static/css/vendor
. (The directorycommon/static/css
only contains sources: no CSS is outputted there.)Now,
common/static/css
only contains sources for the Sass build, andlms/static/css
is only used for output.Change 2: common/static/common/[js|css]/vendor -> common/static/node_copies/[js|css]
To support our old RequireJS-based frontends, a post-install hook on
npm clean-install
copies certain JS & CSS modules intocommon/static/common/[js|css]/vendor
. However, the copied modules' ancestor directory,common/static/common
, is a source for the Webpack build that we need to bind-mount. This violates the constraint that we must not bind-mount items that were previously modified by the build.To resolve the issue, we relocate
common/static/common/[js|css]/vendor
to new directories,common/static/node_copies/[js|css]
. We provide a symlink from the original location to a new location.Now,
common/static/common
andcommon/static/node_copies
can both be used as inputs to the Webpack build, but the latter will not be clobbered when we bind-mount the former. Furthermore, the new directory name ("node_copies") ismore illustrative than the old one ("vendor").
Note: I originally attempted to make this change without the symlink--I updated all references to the old path to the new path. I struggled for several hours to get tests passing for JS using RequireJS, and concluded that I don't understand our RequireJS setup well enough to safely make that change.
Bonus change: log
npm run postinstall
steps to STDOUT so they are visible in CIThis is a small logging improvement that I ended up needing in order to debug this PR, which was helpful enough that I've decided to keep in the PR.
Testing
Here's how I tested:
Setup
I tested this edx-platform branch three different configurations, using latest Tutor Nightly and Devstack:
tutor dev (with bindmount)
tutor local (no bindmount)
devstack
Test playbook
I ran through this basic flow, keeping an eye out for any visual issues or misbehaving components: