Overview: rewriting static asset build for edx-platform to get rid of the python involved and have it all be front-end tooling What does it mean to process static assets?
Build. Turn scss into css, run webpack
Collect. Copy all built assets to a folder
Watch. Run a daemon to look at built assets and rebuild if things change (only for dev env)
Making the collection step simpler:
Previously, you had to use paver as a wrapper around the python management command. We moved the necessary configs into edx-platform so we don’t need paver. We can just run ./manage.py <cms/lms> collectstatic. Result: No more paver!
Before: certain xblocks generated scss and we used those as input to the lms and studio scss. That meant there were intermingled stylesheets
Now: we write separate stylesheets that are included separately since xblocks are optional plugins
This is a step towards reimplementing the build without python
Current: writing GH actions
Ideally, no one notices except maybe that something is faster
We don’t want to click through and look at every asset because literally no one has time for that
Instead: look at output processes from old and new. Generate sha1s for each created file, and compare the list of shas.
Still not a bad idea to spot check
based on an existing action that built all assets for every PR to make sure they were ok
When you compare the diff, how do you know which file is which if the name has changed?
the name only changes for prod builds, not developer builds, so it’s easy to compare
Tips and tricks
Momentum on metrics has slowed a bit. Need to look into Grafana and Prometheus, which would be more useful for the community than Okay anyway
Unclear how long we are willing to spend on this
Spent a lot of time in edx-sandbox world (really would be much smoother if aligned more closely with tutor/community use), no improvements made, just challenges.
Cycle time is very long.
Sandboxes are important for a lot of developer use cases, especially around QA
Opportunities for overcoming the many and varied challenges?
bind-mount has been hard to work on because of inertia required, but I do have a personal goal around it, and will be picking it back up soon.
I would really like to get sandboxes* going, but I don’t have time right now. Would anyone be interested in helping lead this? Farhaan from OpenCraft says that it should be pretty easy with Grove.
*sandboxes could mean several things:
reference environments to hook up to
sandbox: small instance you can spin up to show off a feature
A lot of folks have their own versions, including 2u, OpenCraft, Axim
Grove is an OpenCraft tool for managing Open edX instances, and they already have a way to plug it into GitLab
question: who would be the host for PR sandboxes that come from the community?
Maybe Axim? There would have to be a cost analysis to figure out how many sandboxes Axim could support at any given time
Make it easy for providers to set up their own hosted sandboxes on their own infrastructure
there would be some overlap with hosted development environments
Arch-BOM is going to start planning on developer data project soon
Cloud-based dev work has been pushed to after dev data
Goal: import and modify development data easily for faster start up of development work
Arch BOM keeps getting sniped by event bus and weird upgrades
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.
Metrics was supposed to be a very short thing but has spiraled. We’re trying to rein it in so we can move on to “real” devex things
How to make this meeting the best use of folks' time, especially people who live in different time zones.
Targeted agenda items vs freestyle section
Section in template for “I would like to talk about this specific thing” that could be filled out beforehand?
What role should the discussion of this group’s roadmap or planned work?
“One of the ways to get people to stick around is to sign them up to do things”
Hopefully Arch BOM will be able to pivot to more devex work soon and have roadmaps to share
Keep recording meetings and taking notes. People like them!
send out agenda earlier in the week to give people a chance to pre-populate items
keep on keepin' on
Typically, when we cut the open release branch, there is a 2 month window before the release
There’s usually a lot of backporting in those 2 months
We could use GH actions to help automate the backporting process. Is this devex or BTR?