Paul Hammant's Blog: GitHub Pages as a CMS again
I blogged before on this, but there were some snafus with the usability of the site. I wanted to test the new online editing of resources, that would be crucial to end-user adoption of GitHub Pages (GHP henceforth) as a CMS solution, and couldn’t. Working with GitHub tech-support (Yossef Mendelssohn), it was determined that I’d setup the GHP repositories incorrectly, and should try again with a more regular design.
So I’ve started over.
Incidentally, this stuff (GHP as a CMS) is ready for prime-time now. Have a mostly static-content corporate website? Move it to GHP :)
- I’ve tinkered with my DNS to have rabbieburns.paulhammant.com
- I made a new repo https://github.com/paul-hammant/rabbieburns. I didn’t create a master branch or push anything up to it.
- I went to the admin for that site, and action the wizard to setup GHP. Settings -> Automatic Page Generator
- I cloned the repository down to my Mac.
- I deleted the generated GHP files (I want a different look/feel to the ones offered)
- I copied over my pre-existing Jekyll site for Robbert Burns content without retaining SCM history from where I had it before.
- I added a CNAME file with a single line “rabbieburns.paulhammant.com”, and pushed all that back.
At this stage, the site deployed and was navigable online : http://rabbieburns.paulhammant.com
- I made a second DNS entry for staging.rabbieburns.paulhammant.com
- In github’s web interface, I forked the repo into https://github.com/paul-hammant-fork/rabbieburns
- In that repo’s admin interface, I renamed it to ‘rabbieburns-staging’ making the lasting URL for it https://github.com/paul-hammant-fork/rabbieburns-staging
- I cloned that to my Mac, changed the CNAME record to “staging.rabbieburns.paulhammant.com” committed, and pushed that back.
The second site is now working : http://staging.rabbieburns.paulhammant.com
Making changes through the web interface for ‘staging’ using workflow to get them to ‘production’
- I changed a file in the web interface: https://github.com/paul-hammant-fork/rabbieburns-staging/commit/3a1e~eda1
- I added another: https://github.com/paul-hammant-fork/rabbieburns-staging/commit/234f~8117
Both of these automatically redeployed the site as they were completed through the GHP web interface
In the GitHub admin app for paul-hammant-fork/rabbieburns-staging, I clicked “Pull Request”, and made one comprising those two, and one more that I’d made in a local clone (as a developer would): https://github.com/paul-hammant/rabbieburns/pull/1. I’m going to leave that hanging there, but were I to accept it via the web-interface (subject to permissions), it would merge into the ‘production’ repo and redeploy the site.
This is as non-programmers would use the CMS. Clearly roles/permissions would need to be created for a team. Specifically, not everyone should be able to merge changes from staging to production. You’re also still going to need a hardcore Git expert on hand for tricky stuff (more later).
A clone of both repos into two branches of one repo
Maybe only one person in the team using this for formal CMS needs to a Git expert. There are going to use this facility for tricky stuff, and end-users are going to occasionally turn to them for help (rolling back a change, etc).
Setup like so:
clone ‘production’ to a local machine, as usual
git clone email@example.com:paul-hammant/rabbieburns.git
#_ rename branch to ‘production’
git branch -m gh-pages production
#_ rename the remote to ‘production’
git remote rename origin production
#_ add staging as a second remote for ‘staging’
git remote add staging firstname.lastname@example.org:paul-hammant-fork/rabbieburns-staging.git
#_ bring down the files for that
git fetch staging gh-pages:staging
You can now flip branches quite easily:
git checkout staging more CNAME git checkout production more CNAME
Note: Calling a remote AND a branch the same name, is perhaps foolish.
Making sure that CNAME change never gets merged back to the ‘main’ (production) site
git checkout production git merge --strategy=ours staging git push production production:gh-pages
This is to maintain divergence between the two sites for the single aspect of the domain name.
Here’s that commit: https://github.com/paul-hammant/rabbieburns/commit/90bd~918c
Note there’s no content.
Using ‘–raw’ we can see WTF the commit was all about:
ph7785:rabbieburns paul$ git show --raw 90bd00be138253dce560422394a2caf7c11e918c commit 90bd00be138253dce560422394a2caf7c11e918c Merge: 1044f3f 2729bb8 Author: Paul Hammant <email@example.com> Date: Tue Jan 1 18:09:25 2013 -0600 non-merge of CNAME, to prevent it being offered as a merge again
Note that the pull request mentioned in “Making changes through the web interface….” above, does not contain the change to CNAME, which is exactly what we want.
A Remaining Snafu
Note that I have one repo under ‘paul-hammant’, and the other under ‘paul-hammant-fork’ ?
GitHub won’t allow you to fork an item you already have a fork (or the canonical version) of. It is a rule. I wish they’d push past it, to enable much more corporate use of GHP in the style I outline.