unModified()

Break stuff. Now.

GitLab Pages In A Breeze

Yet another service to serve my blog

April 16, 2016

My blog has quite a history. It started out on HelioHost as a plain WordPress installation, which eventually became a Wintersmith static site updated over FTP. Tired of the manual updating procedure, I moved to OpenShift to have it auto-build on push. Unable to work with CoffeeScript and Jade, I created my own static site generator written in vanilla JS. But writing in Node 0.10, the latest on OpenShift, was a pain. GitHub + Travis could have done the trick but reading about how to set it up was enough to drive me away. Then I remembered GitLab.

TL;DR

  1. Create a repo in GitLab and name it GITLAB_USERNAME.gitlab.io.

  2. Clone the repo.

  3. Create a local directory contents.

  4. Add a .gitlab-ci.yml to the root of the repo containing:

     pages:
       script:
       - cp -r contents/* public
       artifacts:
         paths:
         - public
       only:
       - master
    
  5. Commit and push to the repo.

  6. Visit GITLAB_USERNAME.gitlab.io.

In summary, what the above does was create a page-ready repo. Next is the .gitlab-ci.yml file which tells GitLab CI what to do when the repo changes, specifically just the master branch. Then all the CI has to do is run the pages task which copies over files from contents to the designated static directory public.

If that wasn't really clear, there's a really wordy but also very comprehensive guide to setting up GitLab pages. It covers from repo creation all the way to custom domain addition and SSL support.

GitLab doesn't care how you build your site. There's no prescribed site builder. As long as you can check-in code, have the CI run through them and spit out files that makes sense to a browser, then we're good.

What about the blog?

If this post is present, as well as seeing the GitLab icon as one of the icons up on the top of the site, then it means that the blog is now powered by GitLab.