(Updated 2020-12-19) How this site was made

2020-11-22 — gitlab, gatsby, ci, vercel — 3 min read

I'm writing this blog post as a way to record the steps I took to get this site up and running, as quite a few of the steps were non-obvious, or poorly documented.

I chose a Gatsby starter theme. In my case, I went with LekoArt's Gatsby Minimal Blog
as its simplicity, and awesome font style caught my eye. The handy dark/light mode switcher at the top of the site is also neat!
I chose GitLab pages as my preferred hosting option. Prior to arriving at this decision, I considered going with a WordPress site, or a Gatsby site hosted by a service provider like Bluehost, HostGator, etc. But, considering the contents of this site are static (for now), I realised I didn't need to pay for hosting, when I could "try" running my site on a free option like GitLab pages, and graduate to a paid option if/when I needed to.
I bought a domain through Namecheap. This one is pretty straightforward, as I was able to get a pretty good deal at the time for my current domain, dipack.dev.

Once I had all the pieces figured out, it was time to actually build my website!

Thankfully, building a Gatsby website, especially if you're using a starter "recipe" you like, can be pretty painless, and I was able to get a first version of the site up and running on localhost (the original web hosting service), in 30 minutes.

Then, I followed a tutorial put out by the Gatsby team on how to deploy a site to GitLab pages, which you can find here

. The big difference for me was that while I needed pathPrefixes in my gatsby-config.js when I had my website hosted on dipack.gitlab.io/personal-website, the same setup did not work once I had my custom domain pointing to the instance, as the resource URIs for things like the scripts, and even the pages themselves, were looking for assets beginning with /personal-website. I was able to get around this disabling pathPrefixes.

Finally, in order to get both mail and a website using the same domain, I had to ensure that I was using a DNS A record to point to the GitLab site instances (instead of the CNAME record that GitLab suggests), and that I stripped the host name from the DNS TXT record that GitLab uses to verify the ownership of a domain. For example, if you have the domain foo.com, then GitLab will present the following TXT record to you in its UI:

_gitlab-pages-verification-code.foo.com TXT gitlab-pages-verification-code=123

You must, however, only use the _gitlab-pages-verification-code part when setting the host for the DNS TXT when setting the record, as for some reason, GitLab appends the domain when sending a verification check, leading to it querying for a _gitlab-pages-verification-code.foo.com.foo.com if you use the record provided in the GitLab UI.

At this point, I was done! The site was working fine, with an SSL/TLS certificate issued using GitLab's Let's Encrypt integration (which only worked once I set the DNS A record instead of CNAME), and GitLab's CI/CD runners were working beautifully, deploying my site within a couple of minutes of pushing to the repo (after the first deploy).

Thanks for reading!

Update 2020-12-19

I switched from hosting my site on GitLab pages to Vercel

This was because GitLab pages would not display any changes I made to existing pages, and would only do so for new pages, which, as you can imagine, is a very frustrating experience, especially when building/hosting a website for the first time.

Vercel's project importer was super easy to setup and use, and I was able to complete the switch in less than 5 minutes! Including the time it took to change the DNS settings and issuing a new SSL certificate!