Updating Moodle 3.9.1 to 3.9.7 using git?

Updating Moodle 3.9.1 to 3.9.7 using git?

by David M -
Number of replies: 12

We initially install Moodle using git, and as part of our annual updates, now need to update our servers (firstly, our test server) from Moodle 3.9.1 to 3.9.7.

The current situation:

git status
HEAD detached at v3.9.1
git branch
* (HEAD detached at v3.9.1)
  master

version.php:
$version = 2020061501.00; // 20200615 = branching date YYYYMMDD - do not modify!
// RR = release increments - 00 in DEV branches.
// .XX = incremental changes.
$release = '3.9.1 (Build: 20200713)'; // Human-friendly version name
$branch = '39'; // This version's branch.
$maturity = MATURITY_STABLE; // This version's maturity level.



(We have specified the specific current release when installing servers, as we have unfortunately been tickled by issues in the past when the (not actually) "STABLE" version has moved forward to a new updated release between the times when we setup our test and live sites.)


I'm never entirely sure/comfortable about the exact steps needed to tell git to update to a newer version from the upstream repo. What do I need to do to tell it to update our site from v3.9.1 to v3.9.7?


                        
Average of ratings: Useful (1)
In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Not a git guru, but looks like the 3.9.x was installed using a -b option which restricts to that branch.

On a 3.9 installed without the -b switch:

[root@sos moodle39]# git branch
* MOODLE_39_STABLE
  master

A [root@sos moodle39]# git status for me does show some bash shell scripts and their .txt outputs in admin/cli/ that are not part of core scripts.

In https://docs.moodle.org/311/en/Git_for_Administrators#Obtaining_the_code_from_Git

shows no -b option in acquiring git code.

I don't go after any .dev or .0 release.   To me using .0 release, I feel like an omicron tester.   I always wait for a .1 or .2 to be released.  I can be patient as am not a programmer! smile

So what does git branch -a show?   Does that command on your server acquire information about higher versions available?

Without -b git uses more space in the hidden .git directory ... but I'll trade space for ease of use any day! smile  And one should be able to acquire the point releases easily.

On a test system, one could side load a 3.9.highest to acquire the code witout -b:

git clone git://git.moodle.org/moodle.git [nameofdir]

cd [nameofdir]
git branch -a

git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE
git checkout MOODLE_39_STABLE

Check version of side load ... in [nameofdir]

fgrep '$release' version.php

If higher than your 3.9.1, then:

copy the hidden .git directory recursively and hidden .git files to the running code directory.

cd to running code directory and just to be sure re-issue:

git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE
git checkout MOODLE_39_STABLE

I even run git reset --hard to assure I have highest 3.x.x desired.

Then run git pull and the upgrade.php script in admin/cli/

Maybe, a git guru will jump in here and correct me if I am wrong ... or they have a git command to override the -b restriction of which am not aware.

'SoS', Ken


Average of ratings: Useful (1)
In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
Amateur Gitter myself - came here because of the the "detached head".
wink

Apparently it means you have checked out a commit instead of a branch. 'git checkout HASH' or 'git checkout -b BRANCH HASH' rather than 'git checkout BRANCH'. The result is that your repo loses the contact with upstream, means no way of merging with it again.

I notice that 'git status' has nothing else to report. Which means you haven't changed any code. Then the simplest way to get in to sync is to put the current code aside (rename the directory) and checkout anew. See https://docs.moodle.org/39/en/Git_for_Administrators#Obtaining_the_code_from_Git. This is the "side loading" Ken is referring to.
In reply to Visvanath Ratnaweera

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Agreed if site doesn't have a ton of addons/plugins ... those would have to be re-installed restored doing moving aside current code and acquiring without -b the 3.9 code.

The other way ... cp -rp .git + other hidden .git files to current active code directory means addons/plugins stay in place.  Am all for 'fewer moving parts'. ;)

'SoS', Ken

In reply to Ken Task

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by David M -
Thanks, both. Having slept on this overnight and taken a further look with fresh eyes, fortunately it looks as though our live server was indeed installed so that it is currently tracking the MOODLE_39_STABLE branch:

git branch -a
MOODLE_35_STABLE
* MOODLE_39_STABLE
remotes/origin/HEAD -> origin/master
remotes/origin/MOODLE_13_STABLE
remotes/origin/MOODLE_14_STABLE
remotes/origin/MOODLE_15_STABLE
remotes/origin/MOODLE_16_STABLE
remotes/origin/MOODLE_17_STABLE
remotes/origin/MOODLE_18_STABLE
remotes/origin/MOODLE_19_STABLE
remotes/origin/MOODLE_20_STABLE
remotes/origin/MOODLE_21_STABLE
remotes/origin/MOODLE_22_STABLE
remotes/origin/MOODLE_23_STABLE
remotes/origin/MOODLE_24_STABLE
remotes/origin/MOODLE_25_STABLE
remotes/origin/MOODLE_26_STABLE
remotes/origin/MOODLE_27_STABLE
remotes/origin/MOODLE_28_STABLE
remotes/origin/MOODLE_29_STABLE
remotes/origin/MOODLE_30_STABLE
remotes/origin/MOODLE_310_STABLE
remotes/origin/MOODLE_31_STABLE
remotes/origin/MOODLE_32_STABLE
remotes/origin/MOODLE_33_STABLE
remotes/origin/MOODLE_34_STABLE
remotes/origin/MOODLE_35_STABLE
remotes/origin/MOODLE_36_STABLE
remotes/origin/MOODLE_37_STABLE
remotes/origin/MOODLE_38_STABLE
remotes/origin/MOODLE_39_STABLE
remotes/origin/master
...so hopefully we should not have problems (just 'git pull') when it comes to updating it to the current minor release of Moodle 3.9.

But going back to the current test server, it was obviously installed in a bit of a rush and we must have slipped up somewhere. I guess this is looking like that there is no easy way to have two servers using the same minor release, and that we should probably just stick with tracking the (moving) STABLE branch (even if that results in different servers having slightly different versions), and hope that differences over days/weeks are indeed fairly minor and that it would only be very very rarely that that might cause problems for us again.

Regarding the 'git status' output, I cut out the details of the other modules, etc, that we also have installed, that our copy of the Moodle repo obviously "doesn't know about" (and which it will ignore when/if we do manage to update it).

On the test server:

git branch -a
* (HEAD detached at v3.9.1)
master
remotes/origin/HEAD -> origin/master
remotes/origin/MOODLE_13_STABLE
remotes/origin/MOODLE_14_STABLE
remotes/origin/MOODLE_15_STABLE
remotes/origin/MOODLE_16_STABLE
remotes/origin/MOODLE_17_STABLE
remotes/origin/MOODLE_18_STABLE
remotes/origin/MOODLE_19_STABLE
remotes/origin/MOODLE_20_STABLE
remotes/origin/MOODLE_21_STABLE
remotes/origin/MOODLE_22_STABLE
remotes/origin/MOODLE_23_STABLE
remotes/origin/MOODLE_24_STABLE
remotes/origin/MOODLE_25_STABLE
remotes/origin/MOODLE_26_STABLE
remotes/origin/MOODLE_27_STABLE
remotes/origin/MOODLE_28_STABLE
remotes/origin/MOODLE_29_STABLE
remotes/origin/MOODLE_30_STABLE
remotes/origin/MOODLE_310_STABLE
remotes/origin/MOODLE_311_STABLE
remotes/origin/MOODLE_31_STABLE
remotes/origin/MOODLE_32_STABLE
remotes/origin/MOODLE_33_STABLE
remotes/origin/MOODLE_34_STABLE
remotes/origin/MOODLE_35_STABLE
remotes/origin/MOODLE_36_STABLE
remotes/origin/MOODLE_37_STABLE
remotes/origin/MOODLE_38_STABLE
remotes/origin/MOODLE_39_STABLE
remotes/origin/master
This looks like it does know about the MOODLE_39_STABLE branch, so would the following hopefully work to try to get it, uhh, back on track?

git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE
git checkout MOODLE_39_STABLE            

In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Ken Task -
Picture of Particularly helpful Moodlers

test instance ... what harm would come from trying?  None, me thinks.

Might have to resort to that git reset --hard as last git command before the git pull.

As far as maintaining same point release on both servers, if you finally get test to use git pull and update ... do production server on same day ... you get the same git release.  Moodle issues updates 2 times a week, I've read.

'SoS', Ken

In reply to Ken Task

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by David M -
I gave it a go

git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE
git checkout MOODLE_39_STABLE
git pull
...followed by

php admin/cli/cron.php 
php admin/cli/upgrade.php --non-interactive
...did seem to work to get the test server back on track, thankfully.
Average of ratings: Useful (1)
In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Ken Task -
Picture of Particularly helpful Moodlers

When doing production server itself, might want to put site in maintenance mode to keep others out while performing the upgrade (there is a cli for that).   Cannot run cron in maintenance mode so run the CLI cron right before putting site in maintenance mode then perform the git pull whatever.  Last cli commands - purge the cache then out of maintenance mode. 

'SoS', Ken

In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
So your test instance is different from the live server. What exactly are you testing?
In reply to Visvanath Ratnaweera

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by David M -
Updating Moodle itself is only part of what we need to test (and we assume/hope that that part should be reasonably smooth). We also use a number of other fairly significant Moodle modules (some developed by our own developers) and so it's equally important that we can test that there are no issues with those, before we then try to update the live server.

With the switch to remote working, we had to set up a VM as our current test server (rather than just a spare old desktop) and unfortunately we obviously didn't get setting it up quite right this time.
In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Visvanath Ratnaweera -
Picture of Particularly helpful Moodlers Picture of Translators
OK. So your "test server" is a course development server which has original content, i.e. content that you don't want to lose. Normally a "test server" is a copy of something which you are ready to sacrifice to gain other information like "what will happen if" by doing exactly that. This one is just a second Moodle instance, a course development Moodle.
In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Sounds like you need a test2 that is a clone of production server.  Different FQDN, noemailever and restriction to admin's/developers/selected teachers/some dummy student accounts only.

test2 then would include all your customizations (hopefully not hacked core code).   Now when testing test2 git upgrades that would be closer to actual production server and thus could see what you might have to do with the customizations.

You could end up running your own git repo (core code + includes your customizations).

'SoS', Ken

Average of ratings: Useful (1)
In reply to David M

Re: Updating Moodle 3.9.1 to 3.9.7 using git?

by Michael Milette -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators
When dealing with more than one Moodle site, it is worth forking Moodle to your own GitHub account and then building your Moodle from there. In this way, you can always ensure that your sites are running the same version of Moodle and don't need to worry that Moodle HQ has updated to a minor or weekly release. When you are ready to update your instances of Moodle every once in a while (under your control), you can update your fork to be in sync with Moodle HQ's release.

When checking out a release, you can checkout a branch (e.g., MOODLE_39_STABLE) which gives you the latest Moodle code, or a tag (e.g. v3.9.7). Checking out using a tag results in a detached head. If you have a detached head, you can reset it to the branch's head using the following command:

git reset --hard MOODLE_39_STABLE

You should not need to worry about this affecting your 3rd party plugins as git will only affect the branch's tracked files. Having deployed Moodle using git results in an easy to maintain instance of Moodle. To update, all you need to do is:

git reset --hard MOODLE_39_STABLE
git fetch
git pull

If you have customized Moodle core code, you will also need to re-apply your patches. I save my patches as separate branches based on MOODLE_39_STABLE and then use the git cherry-pick command to apply the individual patches. If you put these commands into a script, it becomes very easy to re-apply the patches. Just be sure to read the results to ensure that there were no merge conflicts that need to be resolved.

As for the following 2 lines you suggested:

php admin/cli/cron.php
php admin/cli/upgrade.php --non-interactive

...I would do these in the reverse order or even at all. Until you run the upgrade script to update the database, cron won't run. This applies whether you are updating Moodle or 3rd party plugins. If you are going to do it, reverse the order of the two lines. The only time that I would do it in the order you indicated is if you experienced failed upgrade. In this case, it might be necessary to run cron in order to clean-up any mess left behind. It's happened to me one or twice over the past 8 years and I could not complete the update process.

As for upgrade.php --non-interactive, I prefer to log into Moodle, navigate to Notifications and go though the upgrade process manually so that I can see any new settings, especially on the test site. Occasionally, I find new settings that I need to modify. If you use the CLI tool with non-interactive, you may never know about the new settings.

On a side note, if anyone has an instance of Moodle that was not installed using git, it is still possible to convert it into a git installation without having to re-install from scratch. But that is a topic for another discussion.

Upgrading Moodle to a new major version involves using git to check out the new branch, upgrading your 3rd party plugins (needs to be done individually), applying any custom patches to Moodle core and performing the database update.

IMPORTANT REMINDER: Moodle versions work in one direction only. You can only upgrade. If you accidently upgrade, you have until the database update to roll back. Once you perform the database upgrade (or upgrade.php on the command line), you cannot go back unless you do a full site restore from a backup. I therefore always recommend making a full backup of your Moodle application files, moodledata and database while in CLI maintenance mode before doing an upgrade.

CLI maintenance mode is different from setting maintenance mode from within Moodle. CLI maintenance completely disables access to the Moodle site for users and for cron. This ensures that there will be no changes made to the database or to the moodledata files during the backup thereby ensuring the backup's integrity. For information on enabling CLI maintenance mode, see https://docs.moodle.org/en/Maintenance_mode#CLI_maintenance_mode.

Hope you find this useful.

Best regards,

Michael Milette
Average of ratings: Useful (3)