Logo

dev-resources.site

for different kinds of informations.

Simplifying switcheroos

Published at
9/23/2022
Categories
static
webdev
ssg
cicd
Author
brycewray
Categories
4 categories in total
static
open
webdev
open
ssg
open
cicd
open
Author
9 person written this
brycewray
open
Simplifying switcheroos

Itā€™s a web meme that began as a line from Jurassic Park:

. . . your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should.

Well, the other day, my oft-mentioned enthusiasm for switching my site among various static site generators (SSGs) manifested itself in an idea that I immediately thought was so cool that I had to make it happen.

And, no, I didnā€™t stop to think if I should.

But the thing is, Iā€™ve heard from and read about others out there who, as do I, like to perform these switcheroos in which they move their sites from one SSG to another. Itā€™s not just moi. So I thought Iā€™d write up the whole thing, just in case my fellow migratory nerds out there might find it useful.

The former way

First, hereā€™s a brief summary of how, before now, I would perform such site moves. The term project below refers to a website instance in my web host of choice, Cloudflare Pages. Terms vary from host to host (e.g., Vercel also calls them projects, while Netlify calls them sites), but you understand what I mean.

For each SSG of interest, Iā€™d have my site's content in a project. Of course, only one project at a time could be the site ā€” weā€™ll call it the Site Project ā€” and so only that one was set to receive traffic for my brycewray.com domain, unlike however many Non-site Projects I might be maintaining.

When I chose to do a switcheroo, Iā€™d have to:

  • Go into the Site Project and disable its settings for that custom domain, thus taking my site offline.
  • Go into the Non-site Project to which I wanted to move the site and set it up for that custom domain.
  • Wait until the host ā€œblessedā€ the change, at which time the switcheroo would become official and my site would be online again.

While experience born of sheer repetition allowed me to do the first two parts in well under a minute, and the subsequent ā€œblessingā€ usually1 occurred almost as quickly, sometimes Stuff Would Happen and my site would be offline for minutes.

Itā€™s not as if my site is mission-critical to humanity or anything like that, but I still was annoyed by that (usually) brief period of offline-ness. I was sure there had to be a better way ā€” other than the obvious choice of never migrating, that is.

This is where my idea comes into play.

The new way

It was obvious that the failure point was in the domain-switching part. The just-as-obvious answer was that I would simply not switch the domain. Instead, Iā€™d set up just one project, to which the domain would always be assigned, and point different repos to that project.

ā€œBut, wait,ā€ you say, ā€œeven that repo switch can involve some period of down-time, right?ā€

Yes, if you do the switchover through the hostā€™s GUI.

But what if you donā€™t?

What if you do it completely through CI/CD?

Bingo.

So hereā€™s what I did.

  1. I created a new project, called static-site.
  2. For static-siteā€™s default content ā€” the repo that the host's GUI assigns to it via the usual Git connection ā€” I assigned a for-testing-only repo which, on publication, has just a couple of minimal pages and nothing more.2
  3. In each SSG-specific repo (i.e., each repo with my siteā€™s real content and using a specific SSG of interest), I created a GitHub Action (GHA) that would publish to static-site, and thus the site.
  4. Then ā€” and this is how the whole trick works --- I make sure that only the SSG-specific repo I want to use has its GHA in the right location (.github/workflows/) so itā€™ll work, while each other SSG-specific repo has its GHA in a standby location which GitHub won't ā€œseeā€ as a trigger point.

This way, I can work with and push commits to each remote repo as much as I want, but only the one I want to be the site repo at any given time will actually have its content published to the website on each push.

Thus, I can effortlessly, instantly switch my site between Eleventy and Hugo, or between Hugo and Astro, or between Astro and . . . well, you see.3

The proverbial ā€œdevilā€™s workshopā€

Whether anyone else might ever have a use for such a method, I obviously canā€™t say, but it works for me. If you can find value in it, there you are.

And, if not: well, try not to pity me too awfully, okay?

Besides, it couldā€™ve been worse: I had a fleeting thought of trying to come up with a monorepo with multiple SSGs and their respective configurations, file/folder ā€œlookup orders,ā€ etc. ā€” so I could share just one set of content among all the SSGs, making switcheroos that much easier. At least I didnā€™t go there.

Well . . . not yet, anyway. [Evil laugh.]

Later note: For those who may be morbidly curious about that last item, be advised that, my curiosity too much to bear, I did attempt just such a monorepo-based approach. While I got it to work with very bare-bones-ish content, I couldnā€™t determine how to make different SSGs respect ā€” or, more accurately, ignore ā€” each othersā€™ components, shortcodes, etc. (at least without show-stopping errors). Thatā€™s where the mad-scientist-level experiment ended.


  1. More often than not, itā€™s a function of how quickly the host can auto-issue a new SSL certificate so the site will have that https: goodness. Under normal circumstances, the cert is issued within a minute. In my case, I get it for both brycewray.com and www.brycewray.com, but these happen sufficiently simultaneously that the doubling-up usually isnā€™t a factor.Ā ā†©

  2. Why did I even bother with that? Because itā€™s the easiest, quickest, least glitchy way of getting the static-site project online at all. Iā€™ve not yet found a way to initiate such a project strictly via CI/CD without first setting up at least a bare-bones presence via the hostā€™s GUI ā€” mainly because there are certain parameters that I canā€™t even put in CI/CD until the project exists. Itā€™s a chicken/egg thing.Ā ā†©

  3. One drawback to such switches ā€” one which will probably keep me from executing them in too willy-nilly a fashion ā€” is that they tend to re-send recent entries in the siteā€™s RSS and JSON feeds. Iā€™m sure thereā€™s a way to avoid that, perhaps through working to make each SSGā€™s feed output as identical as possible, but I havenā€™t yet found it.Ā ā†©

static Article's
30 articles in total
Favicon
The Magic of `static` in Java: One for All, and All for One!
Favicon
First AWS Project
Favicon
Astro vs Visual Studio 2022 as Static Site Generators
Favicon
Dynamic vs Static typing (again)
Favicon
A real life example of using Late Static Binding in PHP.
Favicon
Back to the roots: advantages to static web development
Favicon
Choosing Between Static and Non-Static Methods in PHP: Real-World Use Cases and Code Examples
Favicon
C++, Static Object - Singleton pattern
Favicon
C++, Static Object - share data
Favicon
Hosting static sites with Cloudflare R2 and MinIO Client
Favicon
šŸ˜± Book Release: Eleventy by Example ā€“ Learn 11ty with 5 in-depth projects
Favicon
Host Your Static Website Files for Free with Staticsave: The Fastest and Easiest Way to Share Your Content Online
Favicon
Adding a Table of Contents to dynamic content in 11ty
Favicon
Mix static & client-side rendering on same page with SvelteKit
Favicon
The Top Five Static Site Generators (SSGs) for 2023 ā€”Ā and when to use them
Favicon
Position-relative and absolute
Favicon
Looking for a TinaCMS or Tina Cloud alternative?
Favicon
Editing Content with Hugo Shortcodes: A Shortcode-Aware CMS
Favicon
How to make use of the GitLab CI for Rust Projects
Favicon
Artisanal Web Development
Favicon
C - Static libraries
Favicon
Simplifying switcheroos
Favicon
What is a Static Site Generator?
Favicon
Static vs Dynamic Websites: The Definitive Guide
Favicon
Ten Myths about Static Websites
Favicon
Dart Typing šŸ’« šŸŒŒ āœØ
Favicon
Hosting Static Content with SSL on Azure
Favicon
Watching your Core Web Vitals on Jamstack
Favicon
Automatically update your GitHub Pages website with posts from dev.to
Favicon
Password Protection for Cloudflare Pages

Featured ones: