Moodle in English: managing plugins with git

managing plugins with git

by jon hamill - Thursday, January 21, 2021, 2:18 AM

Hello,

I've got somewhat strange situation that I don't believe has been discussed in the forums thus far and I would like to ask for some guidance from the dev community about best practices for maintaining the Moodle plugins with both git and the 'install plugins' pages from the site.

For context, I am the newly minted tech-lead for this team, am a dev ( postgres + postgREST + elm.js for my fave/choice webstack ), and am also a sysadmin. But I am new to moodle because the previous the previous tech-lead for this was taken off the project due to sudden/unexpected long-term medical leave.

So, I'm familiar with the moodle plugin ecosystem now but I'm trying to get more familiar with the git workflows because we have changes on the test-server's filesystem that are not in git because they were installed from zip files using the site's plugin features.

Ultimately, I need to know a bit more about how to sync up the git repo, the locally modified filesystem, and also best practices for using git submodules moving forward.

In short, I think everything I need to know could be answered from a technical perspective with a full CI/CD answer to the following:

- what, if anything, does an admin/dev need to do on the running/production server to use the code from a git submodule and present it to the running site as a fully-functioning plugin?

If my question is totally off-base and doesn't represent a proper understanding of the real architecture then please do send some lovely nulledge my way and I'll be happy to read up on whatever I'm missing.

best,

-Jon

Re: managing plugins with git

by Howard Miller - Thursday, January 21, 2021, 6:21 AM

I can tell you what *I* do...

I have a github repo with *my* build of Moodle on it. It contains the core code plus all the plugins I use. I don't use git subplugins. I simply add the plugin and commit the new code as a change. When a core update comes out I merge it from Moodle's git repo. When plugins update I use the built in plugin updater (on a dev site, not the live site) and then commit the changes.

I have a development site, a UAT site and then the live cluster so this makes it easy to keep it all in sync and the guys who run the production servers don't have to get into complicated Git stuff.

For full disclosure, I don't like Git subplugins. It's far too easy to mess up and be in the situation of having to read the documentation. Much as I like Git, I really don't like having to read it's dreadful documentation

Average of ratings:Useful (2)

Re: managing plugins with git

by jon hamill - Friday, January 22, 2021, 11:03 PM

Thanks, Howard,

It's good to know that someone else has had success with using the site to take in new code and then committing->pushing whatever changes were made to the filesystem where the code is checked out once the plugins features finish their procedures.

I had been considering this approach because it suits the current makeup of the team, but it does make our repo-management a bit more complicated to document/follow. Our Q/A instance of the site ( for both unit-test and tests where humans click around ) is our 'test' branch rather than our 'dev' branch where new feature-branches would normally be created from when following the usual SDLC dataflows: feature<- ->dev->test->prod/master.

We plan to follow the usual SDLC process for code we write and review ourselves. But using the approach you've found useful for the plugins I guess our code's dataflows would look more like: feature<- ->dev<- -> test -> prod/master; which can be done with appropriate use of 'git rebase' on the dev branch when test branch pushes down new changes, etc.

Thanks again for the feedback, Howard!

Average of ratings: -

Re: managing plugins with git

by Abhijeet Viswa - Monday, January 25, 2021, 3:41 AM

I recently developed a plugin for "internal" use (repo). This is what I did:

* I created a Docker workspace for anything Moodle related (repo). I made the image tailored for my use case (very low disk space required).
* I used a bind mount to mount my plugin repo (inside the extras) folder into the docker container.

I'm not sure if this is an ideal way of doing things but I realized using submodules made things needlessly complicated for me. I could just cd into a sub repo and use it as normal. The contents 'extras' folder and the 'moodle' folder in the main Docker repo is completely ignored and hence there isn't much issue.

The plugin I'm working on is extremely simple and there isn't much chance of needless complicated. Though, I don't see why this solution wouldn't scale for bigger plugins. Hopefully this is of some use to you.

Average of ratings: -

General developer forum

managing plugins with git