Using a git submodule in one of your Openshift apps can be quite useful. I created a Moodle Quickstart and needed to embed Moodle inside my Openshift repo. There are many ways of doing so but most are a pain to maintain if you need frequent updates to keep up with security issues.
So forget about subtrees, manual overwriting with archives etc. use a submodule instead. I’ll post an example with Moodle here, the same can be said about most other apps. Assuming you set up a new app through the web interface:
rhc app git-clone moodle # clone the app locally cd moodle git rm -rf php git ci -m 'remove php dir for submodule' # clean your repo git submodule add git://git.moodle.org/moodle.git php # make php your submodule dir cd php git checkout 10ad21dc9a50c4720bf69fa0224eeb28a892e997 # check out a certain commit inside your submodule cd .. git add -u git ci -am 'add moodle submodule and set to 2.3.3' # go back to your repo root and commit the submodule to it
Now you can push your app to Openshift and you can easily update your app by updating the submodule to a newer commit.
There is one caveat though: you cannot add your own files to the submodule
without having a remote repository where you can store your changes and make
them available to others (in this case Openshift because it will need the
commit with your chages accessible). As you see the submodule is alien to the
parent repository. Everything the parent knows about the submodule is inside
.gitmodules file. It keeps track of the submodule and its attributes:
[submodule "php"] path = php url = git://git.moodle.org/moodle.git
If you also check out the github page you will notice that the submodule repo is set to a certain commit:
If you clone my repository from GitHub you will also notice that the
is empty. That’s because there is nothing. All it does is refer to that moodle
repo commit. You can trigger the clone of that repo but there’s no need to.
Openshift can do that for you once you push it there.
You get the idea. You don’t have control over that submodule. Take it or leave it. So unless you want to fork moodle with your own changes to the repo and pull in changes to that fork you cannot make changes to it.
That’s where we are. However, there is a simple workaround for this on
Openshift that is really slick and easy to set up. You can use one of the
action_hooks that come with each app and that reside in the
.openshift/action_hooks dir in the root of your repo.
In the case of Moodle I needed to place my
config.php in the
php dir where
Moodle expects all the database settings and other stuff to properly run.
Since I already used
.openshift/action_hooks/pre_start_php-5.3 to set the
OPENSHIFT_SECURE_TOKEN (which I described
here) I just added a line which copies the
php/config.php. That means I added a dir with a file
in it to the parent directory
and copied it upon deployment to the submodule folder:
cp ~/app-root/repo/config/config.php ~/app-root/repo/php/
action_hook are called within every deployment there is no need to
manually move files or change the submodule via SSH. The config file can be
added to the Openshift repository and tracked there. A very clean solution if
you ask me.