Heading Back to GitLab

12/3/2020

Journal

In my previous entry, I briefly discussed a move back to Netlify and my reasoning for leaving in the first place... I never did touch on my reasons for going back, but I'll leave that for another time. I've just finished another move, off of GitHub and GitHub Actions and on to GitLab and GitLab CI. On that, I do want to say why...

Actually, first an unexpected benefit: The script for GitLab CI was a bit harder to setup than GitHub Actions. GitHub Actions is a superb ecosystem, clearly, with wonderful custom-made "actions" put together and maintained by other people. That's awesome. GitLab CI, to my knowledge, doesn't have anything quite like that. That sounds like a massive detriment, I know, but it forced me to find some other ways to do things, and led me to using Netlify CLI in the deploy step instead of depending on a custom 'production' branch. Scrapping the 'production' branch is definitely a plus. To be clear, the same would be achievable on GitHub Actions and... if I do get to rewriting the Actions config at any point, I will totally change the deploy the procedure to something more like that. So anyway, the actual benefit of GitLab and GitLab CI for me...

Subgroups. Literally just subgroups. Private subgroups.

I don't like my GitHub repo list becoming cluttered with private and open source and archived projects. I would like to keep it clean, manageable and purely a showcase of my open source work, if possible. GitLab has subgroups, which means I can store my site at a namespace like madebythom/sites and have other namespaces like madebythom/prose and madebythom/screenplays... which is exactly what I've done. It keeps my thombruce namespace clear for more dedicated projects, and greatly reduces clutter. It also means that, say, prose and screenplays with the same title can be stored without a clunky prefix like screenplay_.

GitHub Actions is awesome, but... so are GitLab groups... and sometimes it's just... nicer to be forced to achieve a more complex configuration if it's more robust and can be done precisely the same way across numerous CI services. Actions is very much bespoke.

Anyway, the new setup:

  1. GitLab hosts the source
  2. GitLab CI builds and deploys the site to..
  3. Netlify hosts the built website
  4. Namecheap is the source of my domain
  5. Cloudflare handles DNS for the domain

That's... I think gonna be my preferred approach to static websites and single page applications for some time, unless.,, Yes, unless that is it is something that can or should be deployed directly from an Open Source repo... which I may actually do next for a project called 'Free as in Beer'... after which, maybe I'll look at which parts of my Nuxt setup are similar between thombruce.com and that project and try to pry those out into a separate project which they share.