Migrating the website to GitLab

The first task was to recover the original source code; this was hosted on an old server before github/bitbucket were offering free private repositories. I had setup the website domains to direct to cloudflare so couldn’t use those for ssh. The IP address had to be recovered via the Linode interface and luckily (or irresponsibly) being able to guess the old password.

Because that server was going to be taken down, I copied everthing locally with

rsync -azvh username@ip_address:/home/username/* ./backup

With the repositories copied, I had to upload them to gitlab. I begin by creating a repo. I was hoping that the creation wizard would give me an option to upload local repositories but, alas, no. Instead, following instructions from here, I used

git push --set-upstream [email protected]:JJMinton/website master

which worked like a charm. The post indicates that the repository will be created by this command, but I had created mine previously so no promises.

I also noted in this step, that the repository is quite large, 67.4MB large. This is probably the pdf documents that are served by the site, but I made a mental note to investigate this later.

Next, to build the site and host it using Gitlab’s pipelines and pages features. Creating a CI flow using GitLab’s pipeline feature in the webapp, (this image is of another repository as I was late taking a screen shot), I used the jekyll template provided, , which kicked off a pipeline as soon as I commited. I assume that gitlab does a lookup of the .gitlab-ci.yml in every repository to trigger build pipelines and interogates it for the pipeline configuration.

Upon completion, I navigated to the compiled page (via Settings in the left hand menu > pages > “Your pages are served under: …”) and voila! A few missing resouces but otherwise a served website.

Configuring the domain

The missing resources were because I had the domain name referenced in a few places and, of course, the domain name was still pointing at the old host. This should be the contents of another post but quickly, to redirect the domain name via cloudflare to GitLab Pages:

1. Register the domain name.
2. Register with Cloudflare and point it to GitLab pages, roughly following these instructions:
   1. Cloudflare dashboard > +Add Site to add the domain and click through the wizard.
   2. Cloudflare > Domain > DNS > Set A/CNAME on domain/subdomain to point to the Pages’ address
   3. Set a CNAME record on www.(sub)domain to redirect to the non-www (sub)domain
   4. GitLab project > Pages > New Domain (you will not be able to complete domain name verification yet.)
   5. Set TXT with the GitLab key from the wizard.
   6. Back in the GitLab wizard, complete the domain name verification.

3. Copy Cloudflare’s DNS addresses to the domain registration service (and wait 24 hours).

4. For full end-to-end encuption (“ssl/tls: full (strict)” in cloudlare), then the origin server (GitLab) needs a valid ssl certificate.

Attempt One from here: Set-up origin server certificate from Cloudflare 1. Cloudflare dashboard > SSL/TLS > Origin Server > Create Certificate 1. Input the hostnames, otherwise defaults are fine. 1. GitLab Project page > Settings > Pages > Domains > Edit 1. Copy the Cloudflare generated certificate and paste it into the available box in GitLab pages window. This appeared not to work but is plausibly user error.

Attempt Two: Use GitLab’s “Automatic certificate management using Let’s Encrypt” 1. GitLab Project page > Settings > Pages > Domains > Edit 1. Turn “Automatic certificate management using Let’s Encrypt” on.

Summary

I have been generally impressed with GitLab: the one-stop-shop functionality that GitLab provides is very impressive and the private repositories is a big advantage over github.com. However, throughout the processes I faced numerous GitLab outages, including DNS_PROBE_FINISHED_NXDOMAIN for gitlab.com (but not subdomains) as well as 503, and “An error occured while fetching folder content.” errors for my projects. Of course, my connection may be contributing to this but it is frustrating all the same. Despite this, I will continue with GitLab for the time being and hopefully post here more frequently.

Edit: I later read that gitlab.com were switching their CDN provider to cloudflare on March 28, when I was doing this work.