tcyrus@tcyr.us ~ $

Moving (almost) all sites to GitLab Pages

How I moved most of my sites to GitLab Pages

tags
#GitLab #CI #Pages
published

Introduction

A lot has happened in the last couple of months.

I’m slowly trying to retire an old VPS that I use and I’ve decided to shut down a chunk of things in the process. One of the things I decided to shut down was my own personal Gitea server.

Everything that was a public repo on my Gitea server has now been moved to GitLab.com and I converted a couple of my private personal projects to public ones in the process.

There are some private repos that I decided to zip up and throw it into a undescript folder on my NAS in case I need to refference them again.

Once I completed the migration, I tried poking around with GitLab CI and realized that I could use GitLab Pages as an alternative to my own webserver for most sites.

Advantages

  • Automated Build

    My replacement VPS has less memory than my current one. This means that I need to enable swap in order to run bundle install and jekyll build. This makes GitLab CI ideal for separating builds from deployment.

  • Automated Deployment

    The GitLab CI build can directly deploy to GitLab Pages. I can also configure GitLab CI to deploy to my VPS if necessary.

  • Build + Hosting Transparency

    The build process and hosting setup is documented in the GitLab CI config (.gitlab-ci.yml).

Disadvantage

  • Restricted Control

    Since I’m not hosting the site on my VPS, I have a bit less control over specific parts of the site. For example; motd uses the User-Agent Header to provide a better experience when accessed via curl. This behavior is not supported in GitHub Pages.

  • Inital Setup Time

    This took a decent amount of time to setup.

  • CI Time Limits

    I don’t have to worry about the amount of resources I spend on builds when I’m using my own server. That isn’t the case when using GitLab CI normally. This can be resolved by setting up my own GitLab Runner and then registering it with GitLab.com (see docs)

Low Hanging Fruit

I ported the easy sites over first:

Two of the sites (servers and friends) use client side rendering from a custom backend (which also needs to move). This means that the web app doesn’t need to be rebuilt in order to update the content.

Since I wanted to shutdown my old server as soon as posssible, I tried moving the data to GitLab Snippets. This didn’t work because of a CORS issue with GitLab Snippets. Rather than wait for a fix that might take up to 6 months, I temporarily moved the data to a GitHub Gist. I also tried migrating the data to IBM Cloudant and encountered issues with the documentation and design of the IAM. I hope to move the data to something like Baserow, so I can easily modify the data as well as read the data via api.

EEEH? EASY MODO?

I decided to try migrating this blog to GitLab Pages. If you’re reading this, then it probably didn’t fail horribly.

  • Pull posts via rclone in dedicated task
  • Pass posts to jekyll job in dedicated task
  • Run jekyll in a separate job

I encountered some issues with this step, but it all should be working as of now.

The Final Challenge

Based on the success of porting my Blog to GitHub Pages, I tried to do the same for sheets.tcyr.us.

This was more involved than the process for the other sites. This is mainly because this site depends on another custom package that I designed called foundation-pdf-orbit

  • foundation-pdf-orbit needed to be built via GitLab CI
  • foundation-pdf-orbit needed to push the prebuilt version to GitLab Packages
  • sheets needed to a new CI task dedicated to pulling vendor resources

During this port over, I noticed that my site was not properly designed to handle unusual configurations like this (url paths were not relative paths, so some links broke).

In the end, it all worked out and sheets is currently deployed. Unfortunately, my deployment methodology for foundation-pdf-orbit (rolling release with no breaks) doesn’t work with the npm semver model.

Also, GitLab Packages doesn’t seem to properly handle npm unpublish, so deployment of this package involves some extra steps that I haven’t gotten around to automating yet.

Despite all of this wacky stuff, the site is up and running (last time I checked).

Next Steps

I have a couple of ideas for next steps

  • IPFS objects to store entries and links
  • IPFS pinning for certain assets