When one thinks about hosting one’s Git repository online, one’s first choice is just Github, no questions asked. It’s so successful that it has become the de facto standard of Git solutions in the cloud. It’s so well-entrenched that developers are advised to use it as their portfolio. At first glance, Github has it all: public repositories, group collaboration, metrics, page hosting, on-premise install option, etc.
Major players host their Open-Source code on Github: Spring, Netflix, Google, SAP, etc. I’m also a huge Github user. I use it to share my code for my blog article and also when speaking at conferences when live-coding. Another great feature of Github is Github Pages. For those not familiar with Pages, it’s a great way to host your static - or Markdown-based, websites. In the later case, Github takes automatically care of the Markdown - HTML conversion. Here’s an example of mine: the Github repository and its child moorevaadin.com website.
However, I found myself more and more frustrated with Github’s limitations. I’m not complaining since I don’t pay anything but stating a fact. It started very simply: non-paying users can only have public repositories, yet, sometimes, I need to host code that I don’t want to keep to myself. For that, I used Atlassian’s Bitbucket. Non-paying users of Bitbucket enjoy 5 private repositories. That’s not a lot, but that was enough for my needs.
Recently, I needed to host another blog on Github Pages. However, I wanted it to use Asciidoctor format instead of Markdown. I’ve used Markedown exclusively for my last book and it has nothing regarding linking to code snippets. Basically, it’s just copy-paste and you have to keep everything in sync yourself. On the contrary, Asciidoctor has such a feature, either by line-number or by tagging in the original source code. Good news, Asciidoctor offers a Jekyll plugin. Bad news, this isn’t supported by Github out-of-the-box. Github will render Asciidoctor files in HTML when browsing Github but will not generate the website as with Markdown.
Of course, there are workarounds - or to be specific, at least one that I know of. As the Github Pages build is private, you can plug in the Travis build tool and hack around it. I stumbled upon this article that describes how to do it. As you can see, this unfortunately is not trivial. I was really disappointed to have to sign in to Travis just to achieve that and started looking for alternatives.
It didn’t take me long to find GitLab, another Git cloud solution. Where Github needs a dedicated third-party build tool, GitLab has its own tool, fully integrated. Even better, generation of the site just takes this very short file:
image: ruby:2.1 # the script will run in Ruby 2.1 using the Docker image ruby:2.1
pages: # the build job must be named pages
script:
- gem install jekyll # we install jekyll
- gem install jekyll-asciidoc
- jekyll build -d public/ # we tell jekyll to build the site for us
artifacts:
paths:
- public # this is where the site will live and the Runner uploads it in GitLab
only:
- masterAnd this week, I just discovered that Github cannot protect branches - especially master, against direct pushes. What it can do is prevent force pushes and/or check for a number of build statuses before merging. However, Gitlab offers that option. Finally, it also provides unlimited private repositories for an unlimited of users.
Probably, there are many more options to explore on GitLab. Be sure I’ll do that in the following weeks. And I’d advise you to do that too, you might find something missing in more well-known solutions.