Upgrading Moodle to specific new minor version using git?

Upgrading Moodle to specific new minor version using git?

by David M -
Number of replies: 11

Hi,

We have an installation of Moodle 3.5.0, which was downloaded (following someone else's advice) using:

git clone -b v3.5.0 git://git.moodle.org/moodle.git /var/www/html/name_of_site

It is now time for us to update our installation, and we would like to update to what is currently the latest Moodle 3.5 release (as this is the current LTS release).

We would like to install this specific minor release (and not the moving MOODLE_35_STABLE) because, between testing the in-place update on our test server, and doing the same on our live server, it is possible that a new minor release may come out, and may lead to subtle differences which then would not have been picked up by our prior testing.

I have had a look at the Git for Administrators page, but I am not sure how to update to a specific minor release (I am not very familiar with more advanced git usage).

Can anyone advise what the correct git syntax for this would be?

Also, it is really the case that all that I would need to do would be to put the site into maintenance mode, update using git, and then disable maintenance mode? If there are any required changes to the database, would I need to do anything, or would Moodle detect this and perform any behind the scenes updates when it restarts?

Thanks for any advice.

Average of ratings: -
In reply to David M

Re: Upgrading Moodle to specific new minor version using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Before 'diving into this' ...

what do you get with: fgrep '$release' version.php

while in the code directory.

Comment:

Since you didn't install with -b (which restricts to branch) you didn't see this (displayed just one time):

Note: checking out '46574904afd39578fa4146bf1fc5c401ac680aa6'.

You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

if the release you have is 3.5.0, you've not 'enjoyed' any of the code fixes/security updates to that LTS version. :\

https://docs.moodle.org/dev/Releases#Moodle_3.5_.28LTS.29

Bug fixes for general core bugs in 3.5.x ended May 2019 (12 months).
Bug fixes for security issues in 3.5.x will end 10 May 2021 (36 months).

3.5 is now:

fgrep '$release' version.php
$release  = '3.5.7 (Build: 20190708)'; // Human-friendly version name

There is a way to get there but it's kinda involved.  Am not a git guru but have 'worked around'  the -b issue. :|

Hint: you can tinker with acquiring moodle code via git on local laptop/workstation ... easier if it's Mac ... but could also tinker in another directory of your server ... like a /home/gittinker to which you copy recursively the code server is using.

from /var/www/html/name_of_site

cp -rp * /home/gittinker/

and to make sure you get hidden stuff

cp -rp .* /home/gittinker/

What you do in there will not affect site and you can 'practice' before working with sites real code.

'SoS', Ken


Average of ratings: -
In reply to Ken Task

Re: Upgrading Moodle to specific new minor version using git?

by David M -

Hi Ken, thanks for your reply.

$release  = '3.5 (Build: 20180517)'; // Human-friendly version name

We did install using 'git clone -b' and so I did see the git output you quote, but not having very much in-depth git knowledge, I didn't understand what it meant (I have to say, I find git a lot more cryptic than svn in many ways).

We are aware that we have not installed any Moodle updates since the initial install, but unfortunately we do only have the resources (and permitted maintenance windows) to do one annual server update (distro package updates aside) and we also don't have the resources to plan for the possibility of a Moodle update at any other times possibly breaking things (I have obviously flagged up these issues, but they are outwith my control).

(In a previous year when we tried MOODLE_XX_STABLE as the install version, we got bitten by the stable release changing between our test server build and our later (attempted) live server build, and the change not working with our question type, which is why we now install the specific minor version that is available at the time we start testing.)


We are, of course, planning to test the update process on a test server before updating the live server: the problem is that I don't know what git magic I need to do.

'git pull' would, I think(?), update the files to the latest version in the repo, but there is still the potential problem of the "latest" version changing between updating our test server, and then updating the live server for real. That's why I want to specifically update to 3.5.7 (or whatever the minor version is at the time that we are ready to start testing).


Average of ratings: -
In reply to David M

Re: Upgrading Moodle to specific new minor version using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Resources and maintenace windows - who doesn't have those problems with a moodle site that is used?  Everyone can 'empahsize'.  Those 'battles' to be fought internally.  But using git (in the least complicated fashion) is the 'smartest' strategy.

We are talking about the past ... and quite some time ago ... where no one probably remembers what was done (exactly) on the test system.

Was the test system moodle *cloned* from live?

If so that should have git configuration exactly has live - with the -b restriction - no branches set and it would also have your customized 'question type'.  I'll also bet some additional themes were installed.

And from what you've described about having issues with test system, sounds like test system wasn't cloned but built and in attempting to update (NOT upgrade) some set up was different.

So my first recommendation, clone your live system to a test system again ... remember, your live system has been used for quite some time now.

Once that is done, this is probably what you'll see:

Doing a git branch -a shows no branches so git pull command becomes more involved (un-necessairly).

git pull begets:

You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

git pull <remote> <branch>

man git pull

Look for the section on REMOTES which also talks about branches.  And focus ... goal is to get core code updates ... not upgrades.

The above is more complicated than it needs to be.  Installed *without* -b and using:

git branch --track MOODLE_35_STABLE origin/MOODLE_35_STABLE
git checkout MOODLE_35_STABLE

Any git pull would be against that branch.  Don't change the branch nor check out any higher version ... it stays 3.5.x.

If one does that today ... one would get:

3.5.7+ (Build: 20190712)

Because -b was used, you cannot do above.

BUT ... one could 'side load' on test server a 35 branch to another directory, move out/remove the hidden .git directory in test servers 'live'code.  Copy the hidden .git directory from the side load into code directory. And with an additional git reset --hard + git pull one would have the highest 3.5.x available.

*and* server would be ready to test upgrades/march to, the next LTS release.

Now I know am not answering your question specifically ... you want know git pull <remote> <branch>

'SoS', Ken


Average of ratings: -
In reply to Ken Task

Re: Upgrading Moodle to specific new minor version using git?

by David M -

After the minimal OS install is completed, both the test, and then the live, servers are set up for Moodle using the same script.

They are identical software-wise, the only difference being that the test server has a relatively small amount of test course data on it, and the live server is, well, live.

(My mention of a previous server setup ending up with different minor versions of Moodle on each of them is perhaps confusing, I only mentioned it to explain why we now expressly specify the exact Moodle release that we want to install (or update to).)


Regarding: 

git pull <remote> <branch>

…the problem is that I don't know what the values I need to substitute in there would be.

We do specifically want v.3.5.7 (or whatever the current release is at the point we are ready to "go"), rather than the branch MOODLE_35_STABLE, which, despite the name, changes every few weeks (and could give us the problem of different versions on the test and live servers).

Average of ratings: -
In reply to David M

Re: Upgrading Moodle to specific new minor version using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Moodle code is updated every week.  In your situation with 3.5 however, you can only go as high as the last point release ... 3.5.7+ ... there is no more after that.  If one did the test server now, highest would be 3.5.7+.   If a week later you got around to live server, it also would be 3.5.7+.

Can't go any higher than the highest point release.

Let's see if I can't say it again ... because -b was used, there is no branch.   git branch -a will show that.

And yes, I said, I wasn't answering specifically ... and yes I know you want to know what to plugin to that god awefull command: 

git pull <remote> <branch>
Have you looked at "man git-pull" for the explanations to remote and branch?

Here's a clip for REMOTES:

REMOTES
       The name of one of the following can be used instead of a URL as
       <repository> argument:

       o   a remote in the Git configuration file: $GIT_DIR/config,

       o   a file in the $GIT_DIR/remotes directory, or

       o   a file in the $GIT_DIR/branches directory.

       All of these also allow you to omit the refspec from the command line
       because they each contain a refspec which git will use by default.

and other related in man:

Named remote in configuration file

Named file in $GIT_DIR/remotes

Named file in $GIT_DIR/branches

https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

which, if I understand them, requires you to edit files in .git directory.

-b was meant for programmers ... that's my conclusion.

Not sure anyone could tell you so you could 'copy and paste' ... could be going down a very deep rabbit hole!

And now, am beginning to think I should have never responded ... and allowed a programmer to respond! :|

Here's what I do know ... first hand experience ...

I have multiple instances of Moodle on a couple of servers installed via git but NOT with -b. 

A 3.4, 3.5, 3.6, and a 3.7 ... in all of them, to get an update to code ... like 3.5.x to highest 3.5.highest, I only have to do 'git pull'.   Simple.  It works. And it has worked for years with just one time having a minor hitch - only one day ... caused by the Moodle git hub having issues that day - beyond my control for sure.   But, there was a simple ... I need simple ... work-around ... in choosing another protocol ... https vs git. 

Calling all git guru's ... Op needs help that I cannot provide! :|

'SoS', Ken


Average of ratings: -
In reply to David M

Re: Upgrading Moodle to specific new minor version using git?

by Ken Task -
Picture of Particularly helpful Moodlers

You've never said what you have tried ... so ...

After spending a few hours on this and experimenting with git on a Mac laptop ... just git ... not a real moodle server ...

Try this:

In your code directory:

git checkout -b MOODLE_35_STABLE origin/MOODLE_35_STABLE

Hopefully, you will see:

Checking out files: 100% (1789/1789), done.
Previous HEAD position was 46574904afd Moodle release 3.5
Branch 'MOODLE_35_STABLE' set up to track remote branch 'MOODLE_35_STABLE' from 'origin'.
Switched to a new branch 'MOODLE_35_STABLE'

* see potential catch 22 below ..

to check:

fgrep '$release' version.php

hopefully you will see:

$release  = '3.5.7+ (Build: 20190712)'; // Human-friendly version name

To update ... extra, extra mile here ... still in moodle code directory:

php admin/cli/cron.php

php admin/cli/maintenance.php --enable

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

php admin/cli/purge_caches.php

php admin/cli/maintenance.php --disable

Then check site with browser.

* Potential 'catch 22' ... because you've mentioned a customized question type but no details to that ... like 'true' addon or hacked core code?  If the git commands hickup or spit out something about cannot do this and mentions your customized question type ... it might have suggestions as how to handle it.   Guess: git stash and repeat commands.

IF your question type was a hack or core code ... stashing might bite later.

Ok, having gone the 'extra mile or two' with this one, all I can say is 'good luck'!   But do share back how it went with your testing server.

'SoS', Ken

For others reading this ... here is my strongest/best/simplest advice ... don't use -b!


Average of ratings: -
In reply to Ken Task

Re: Upgrading Moodle to specific new minor version using git?

by David M -

Thanks again for your advice.

I'm afraid I'm not sure what you mean by:

"you can only go as high as the last point release ... 3.5.7+ ... there is no more after that.  If one did the test server now, highest would be 3.5.7+.   If a week later you got around to live server, it also would be 3.5.7+."

What does the "+" in the version string mean?

Regarding later updates to the MOODLE_35_STABLE branch, are you saying that there will now be no more updates to that branch at all? I know that it no longer gets bug updates, but is there not still the potential for further security updates during the rest of its lifespan? (My concern is to make sure that we don't end up in a situation, as we did on a previous occasion, where the test and live servers ended up with slightly different versions installed (with unexpected side-effects), because 'stable' had moved on slightly between our test and live installs?)


I tried your

git checkout -b MOODLE_35_STABLE origin/MOODLE_35_STABLE

suggestion, in a spare test folder with the Moodle code cloned as per my original description, and got the same result as you. (I couldn't test the next part with the admin commands, as there was not actually a site installed, only the code fetched.)

Regarding our additional question types, yes, these are question types which have been added to our site from their own repo, not hacks of core code.


It does sound rather as though we have unfortunately found ourselves in a a bit of a "To get to there, I wouldn't start from here" situation.

Would an alternative escape route for us perhaps be to rename our current Moodle folder out of the way, download afresh by following the git instructions, and then copy our original config.php file back into place? Or does a Moodle install (admin/cli/install.php) alter Moodle files, or only the database?

Average of ratings: -
In reply to David M

Re: Upgrading Moodle to specific new minor version using git?

by Ken Task -
Picture of Particularly helpful Moodlers

+ means there have been additions to release ... not enough to be considered a point release ... like 3.5.*thisnumberhere*.  Normally one sees '+''s after a .0 release the very next week of the initial .0 release.  And very minor update when code is 3.5.2 and a minor update was available, then version would appear as 3.5.2+

Moodle releases code each week.  In the case of 3.5 LTS no more code fixes for errors, only security updates.

If both servers were installed with -b ... then they both would have to use the same git checkout -b ... blah command.   Thus would be getting exactly the same updates - no matter when one runs that command on both ... same day, same week or different day, different week.

Command has nothing to do with the date/day you run it but command would/might get updated secure code.  Isn't that what you want?

If you get the same results as I showed, then it was successful!   And to verify, the 'fgrep '$release' version.php check showed the code is highest available 3.5.x.

If the updated code has been acquired, then the database has to be 'informed' ... thus php admin/cli/ script to update is run.

There is one way to find out if it works for you or not ... on test site, backup what you have.  Be sure to include moodle version number and date/time stamp in filenames of those backups. Then do it!

'SoS', Ken



Average of ratings: -
In reply to Ken Task

Re: Upgrading Moodle to specific new minor version using git?

by David M -
Hmm, updating my test site did the following (which is not quite what I expected):

root@temple:/var/www/html/temple421# git checkout -b MOODLE_35_STABLE origin/MOODLE_35_STABLE
Previous HEAD position was 46574904af... Moodle release 3.5
Branch MOODLE_35_STABLE set up to track remote branch MOODLE_35_STABLE from origin.
Switched to a new branch 'MOODLE_35_STABLE'
root@temple:/var/www/html/temple421# grep '$release' version.php
$release  = '3.5.1+ (Build: 20180803)'; // Human-friendly version name

I was expecting the site to update to version 3.5.7+ ?

Average of ratings: -
In reply to David M

Re: Upgrading Moodle to specific new minor version using git?

by Ken Task -
Picture of Particularly helpful Moodlers

Do a git pull by itself now that a branch has been set.

Then check: fgrep '$release' version.php

hopefully: $release  = '3.5.7+ (Build: 20190712)

Then upgrade via admin/cli/ scripts.

'SoS', Ken


Average of ratings: Useful (1)
In reply to Ken Task

Re: Upgrading Moodle to specific new minor version using git?

by David M -
Many thanks, Ken. That seems to have worked successfully now.
Average of ratings: -