...
Notetaker: Rebecca Graber (Deactivated)
Diana Huang
Jeremy Bowman (Deactivated)
Discussion topics
Item | Notes |
---|
Start the Zoom recording! | |
Scheduled Topics / Demos | Kyle McCormick - Switch to Google Meet going forward? Kyle McCormick - My schedule for the next couple months Kyle McCormick - New static assets build is here – let’s optimize our Docker images! Demo Building sometimes garbage collects image layers, so you may end up rebuilding when you thought you were already built paver update-assets replaced with the scripts at the top of edx-platform/package.json eg: npm run webpack, npm run compile-sass, npm build to do both tutor dev run lms npm run build-dev runs webpack & compile-sass better output from compile-sass note: fed-bom is working on upgrading webpack in edx-platform which might speed things up even more
no python requirements for the build except click and lib-sass, which does still take a while to install tutor requirements folder is where you add special requirements via private.txt rebuilding the dev images after doing this is slow and annoying (6-7 minutes because it rebuild static assets) Not anymore! static assets get cached . Down to 90s dev mode does not collect static assets, we still do it in prod
Q (Becca): What do you mean by not use this in production yet? Q (Regis): What is worrying you about putting this in prod? Q (Jeremy): Is there any subset of edx-platform where porting to an MFE will remove the bulk of the sass? Course-preview Studio authoring
Q (Becca): Hacking on edx-platform and a dependency at the same time? Why do we have to rebuild the image in Tutor and not in devstack? Bind-mount dependency folder into the same container this is not as easy in Tutor as devstack to add the dependency to the container, it’s most convenient to have it inside edx-platform and modify the requirements file In devstack, running pip install -e is an ephemeral change to the lms container. if you bring devstack down and up, that change is lost. In Tutor, you make the change to the image itself, so changes stay when you bring up and down Could conceivably make a plugin to bind-mount the necessary requirements directories. This may go into the tutor project.
Kyle McCormick / Régis B. - Tutor MFE dev performance improvements? (Potential demo) Only one MFE container in dev unless you bind-mount another MFE Problem: it was difficult to run openedx in dev mode in Palm due to the number of MFEs. Each development MFE was running with npm run start which has hot reload, but slows down everything and eats the CPU Solution: Run all MFEs using a static webserver like we do in prod, in a single container. How to detect which MFEs still need hot reloading? The MFEs will be bind-mounted in. For those MFEs, run a separate container that still runs npm run start May require a rebuild since you’re also mounting node-modules Was pretty easy to implement since we do run-time configuration for MFEs MFE container listens to many different ports in development
|
Cross Pollination | |
Challenges Each challenge should have a follow up action. If you have an idea for follow up actions, add it. Or if you aren’t sure, leave it blank. We’ll discuss all actions either way.
| |
Successes | Regis made many Dockerfile improvements which made things faster and more clear! After Kyle’s work we are well on our way to making image building way faster, and it will get faster with all the frontend code we remove! |
Suggested Action Items | Last Time: This Time: |
After the meeting… | Make an agenda for next time (tip: copy this page). Axim: Paste in the Zoom link once it’s ready. Paste these notes and next week’s agenda in #wg-developer-experience
|
...