The cookie cutter project by @lpm0073 builds the docker images pushes it to ECR by AWS using GitHub workflow. Everytime we build image it takes close to 40 minutes because it’s done by GitHub runners instead of doing it on physical device. Hence there is no cache. To avoide this we can run these workflows locally (from bastion machine) which means while running workflow next time we will have cache and take much lesser time. This helps in making smaller changes easier particularly while developing new features.
I use act routinely when I need to test GitHub CI before pushing changes upstream. Act works by running a Docker container locally. But building a Docker image inside a Docker container is not trivial. I used to build the Tutor images in a Kubernetes cluster. But that was just too difficult: very often the nodes were running out of disk space. Upgrading Kubernetes clusters was also a pain. So I moved back to building images locally: for that I use the docker:dind image, and it works great so far – though the setup is a little convoluted.
I suggest you either run a self-hosted GitHub runner, setup Docker caching or figure out how to build Docker images remotely (with the dind images for instance).
thanks @regis. the self-hosted runners look very promising, especial given that these can run locally on Windows and macOS. i’ll read more about these and will probably have time later this week to try to prototype something in the Cookiecutter. i’ll report back after i know more.
@keithgg Thank you for the meeting recap! And here is the video recording (chat log):
I’ve sent a calendar invite for the the next meeting, which will be in 2 weeks, on 2023-01-24T17:00:00Z in this Zoom room. I’ve made it recurring to simplify the planning.
My apologies for not having properly followed the agenda for the last meeting btw, but I felt it was useful to hear from the 2U participants who have just joined us. This has delayed a bit the review of the status of the work we had scheduled for yesterday, as we didn’t have enough time to discuss it, but we’ll try to cover this asynchronously until next meeting, and dedicate more time to it during the next meeting.
Here is the proposed agenda for that next meeting - don’t hesitate if you see any changes or additions:
Assign scribe role, greetings & introductions as needed. (5 minutes)
@Felipe Since the formal review period is over, it would be better to merge it provisionally - this way it becomes accessible at Open edX Proposals Index — Open edX Proposals 1.0 documentation and it’s clear that it’s the way we have agreed on for now. Then when refinements are done, we can always update the OEP. It makes it easier for others to open PRs against the document, too.
Yes, both are moving forward. I’ve commented on the first one to follow-up with @regis . For the second one, we need those who want to have access to the repo to mention it on the ticket.
We looked at the ticket very briefly during the meeting. I posted an update on the ticket just now. IMHO this one is not urgent so there is no need to decide now while some of the questions of scope are still a bit fuzzy. I’m hoping we’ll get more context to make such a decision in the future after other pieces have fallen into place.
Yes we discussed it and @lpm0073 is still planning to do it.
We looked at it briefly and decided to follow up async so we have more time to consider it.