Moodle plugin development with moodle-docker vs Lando: which environment integrates cleanly with an existing codebase and CI pipeline?
0 reputation · 16 Mar 2022, 04:42 UTC
0 reputation · 16 Mar 2022, 04:42 UTC
Our team maintains several Moodle plugins and wants a repeatable, version-controlled development environment that every developer and our CI pipeline can reproduce identically. We are deciding between the official moodlehq/moodle-docker compose setup and the Lando-based moodle-lando recipe, targeting a recent Moodle 4.x branch with PostgreSQL.
The integration boundary is where the two approaches seem to differ most. As I understand it, moodle-docker mounts the entire Moodle codebase and expects manual config.php adjustments for non-standard ports or reverse proxies, while Lando mounts only the plugin directory by default and assumes a particular directory structure. Our repositories hold only plugin code, not a full Moodle checkout, and CI jobs need to install a pinned Moodle version, run PHPUnit and Behat, and tear everything down deterministically.
Uncertainty: I have not found an official Moodle recommendation covering core versus plugin development for these two options, and I am unsure how each handles pinned PHP/database versions, database persistence across rebuilds, and Xdebug port mapping inside CI runners. Version assumptions here should be verified against the current moodle-docker repository and Lando plugin documentation.
Which environment maps more naturally onto a plugin-only repository layout without restructuring existing projects?
Can either setup pin Moodle, PHP, and database versions declaratively enough that local and CI runs are guaranteed identical?
How do teams typically handle config.php templating and Xdebug in CI with each option?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.