ITNOOBS was migrated to GitLab Pages just before new year 2020!

Why GitLab?

  • Built-in CI/CD
  • Free Private repos
  • Hosting from private repos

GitHub has been catching up too:

But still no hosting from a private repo and by the time GitHub Actions was announced I was already planning the move.

Anyway, to start things off, I:

  • Signed up for GitLab account
  • Created (private) group: itnoobs
  • Created (private) project in itnoobs: myblog
  • Generated SSH key pair for access

This structure, as suggested in this blog post, is great for separating your projects and sites as well as preserving the root level site or project (i.e. for future use.

Since GitLab CI/CD would take my local configuration for Ruby and Gems and generate the site exactly as I would locally, I decided to refresh and standardize my local environment:

  • Clone Jekyll Minima repo
  • Download or clone itnoobs repo from GitHub
  • Refresh (re-install) my local Jekyll environment
  • Modify and add selected styling, image and posts from current to Minima
  • Create CI/CD configuration (.gitlab-ci.yml)

I switched (from Windows 10) to Ubuntu Desktop and Visual Studio Code over a year ago and my local environment has matured since New Site: Jekyll & Github which pictured a very basic process of creating content and generating the static site.

Local environment setup:

  • Install VS Code snap install code --classic


  • Install Git sudo apt install git
  • Install Ruby sudo apt install ruby ruby-dev
  • Install Bundler sudo gem install bundler
  • Create the project folders mkdir /home/<username>/projects/<blogname>/
  • Switch to project directory and clone Minima theme git clone .
  • Create a Gemfile touch Gemfile with Ruby gems to install

      source ""
      # Hello! This is where you manage which Jekyll version is used to run.
      # When you want to use a different version, change it below, save the
      # file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
      #     bundle exec jekyll serve
      # This will help ensure the proper Jekyll version is running.
      # Happy Jekylling!
      gem "jekyll", "~> 4.0.0"
      gem "nokogiri"
      # This is the default theme for new Jekyll sites. You may change this to anything you like.
      gem "minima", "~> 2.5"
      group :jekyll_plugins do
      gem "jekyll-feed", "~> 0.12"
      gem "jekyll-target-blank"
      gem "jekyll-paginate"
      gem "jekyll-seo-tag"
      gem "jekyll-sitemap"

    Install required libraries for nokogiri sudo apt install zlib1g-dev zlib1g, otherwise you’ll see something like this after running bundle install:


  • Run bundle install to install gems
  • Run bundle exec jekyll --serve to run a local version of site on port 4000 (this is accessible from your local machine only at http://localhost:4000/). Alternatively you can run bundle exec jekyll serve --host=<IPADDRESS> to make it accessible from anywhere in your network.

Bundler makes it easy to keep your Ruby environment consistent. You can have different Gems and versions of them installed in different projects.

Create GitLab CI/CD Configuration:

See this blog post or this project for more details.

The CI/CD configuration runs a few tasks using GitLab Runner:

  • Pull a Ruby docker image
  • Create Bundler environment using Gemfile
  • And finally use Jekyll to generate the static site

Here’s my .gitlab-ci.yml :

# requiring the environment of Ruby 2.5.x
image: ruby:2.5

# add bundle cache to 'vendor' for speeding up builds
    - vendor/

#set env to production
  JEKYLL_ENV: production

  - bundle install --path vendor

# the 'pages' job will deploy and build your site to the 'public' path
  stage: deploy
    - bundle exec jekyll build -d public/
      - public
    - master # this job will affect only the 'master' branch

JEKYLL_ENV is set to production to include Google Analytics

Upload Site to GitLab:

With everything ready, we can configure Git, add the SSH key and upload the new site to GitLab:

  • Set local Git username and email git config "USERNAME" & git config "EMAIL ADDRESS"
  • Since this is an existing local repo git remote add origin remote <repo url>
  • Copy SSH key to /home/<username>/.ssh/ & ssh-add /home/<username>/.ssh/<privartekeyname>
  • I use an SSH configuration file, because I have different private keys for GitHub, GitLab and internal Linux VMs and too lazy to type in username@hostname :

      Host Internal
              HostName *.<INTERNAL DOMAIN> ## or network range
              User <username>
              IdentityFile <path-to-key>
      Host Github
              Hostname *
              User <email>
              IdentityFile <path-to-key>
      Host Gitlab
              Hostname *
              User <email>
              IdentityFile <path-to-key>
  • Create a gitignore file to exclude _site, vendor folders and lock or hidden files:
      !.gitlab-ci.yml #this one should NOT be ignored
  • Finally git add . , git commit -m "meaningful comment" & git push origin master
  • And monitor GitLab pipeline as it picks up the changes and generates the static site


According to GitLab blog, after a successful build, site should be available at, but I had some trouble with that so raised an issue here. Next I added to Pages and verified with it a TXT record. Let’s Encrypt certificate was automatically issued within 10 minutes.


Domain Name Service Migration:

In order to verify, GitLab checks for a TXT record and this was only available with CrazyDomain’s Premium DNS for an extra $19.95. I decided to sign up for a free CloudFlare account instead, then added as a site and repointed name servers from CrazyDomain to CloudFlare.




Besides DNS function, the free tier also packs a lot of other features such as proxy, caching, SSL and analytics.


The end result is a very smooth delivery of new content to the site with much less work, thanks to automation!