dev-resources.site
for different kinds of informations.
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.
- I created a new project, called
static-site
. - 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 - 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. - 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.
-
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.Ā ā© -
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.Ā ā© -
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.Ā ā©
Featured ones: