Some thoughts

directly from the furnace

Custom config files in Openshift submodules

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:// 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 the .gitmodules file. It keeps track of the submodule and its attributes:

[submodule "php"] 
path = php 
url = git://

If you also check out the github page you will notice that the submodule repo is set to a certain commit:

github: moodle path is set to commit

If you clone my repository from GitHub you will also notice that the php dir 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 config.php from config/config.php to 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/

Since the 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.