Logs of the creation of bitesyzedtechdiary
FINALLY FIX PROD!
This was not the first thing that happened today. I am hardly that skilled. But it was perhaps the most exciting tech event of today.
The solution had been staring at me the entire time. The entire time.
I did what every self respecting dev does. I read the source code.
No. I tried changing random things and blaming it all on GitHub. After all
It worked on my machine!
I spun up containers left and right, locally and remotely, and made a bunch of other discoveries.
Eventually I realised that the same code and config were having different results on my local and remote machines. The local didn’t have broken post urls, but the one on my server, did?
So I shut everything down. Cleared the cached builds in the
directory and started a fresh container. Now that a fresh container on the
github-pages image was just as broken,
I suspected that it might just be to do with the version
of Jekyll that was being used.
And that was it.
This whole time I had been thinking maybe GitHub does something more!
But the only thing it does, is be outdated. Perhaps I was too harsh on them.
Earlier I had complained about not being able to use
remote_theme in my
local env because it was a GitHub feature. But I now know it’s actually
just another gem, a Jekyll plugin called
jekyll-remote-theme. Well that
has made my life easier.
Or so I thought. Even after installing the gem, it didn’t work. I knew that
I ought to tell Jekyll to use
jekyll-remote-theme. And that’s what
plugins key in
WAIT! So if adding a gem’s name to
plugins enables it…
Fixing the RSS feed
plugins: - jekyll-remote-theme - jekyll-feed
Tada! So now the feed is generated too!
Maybe this wasn’t a GitHub thing either. When I ran local containers of
Jekyll I ran the latest and greatest
(of the time) after all. And that was Jekyll version
4.2.0. Wayyy ahead
of GitHub Pages’
SSH’s Port Forwarding
never really made sense.
What was local, what was remote?
ssh -L even supposed to be used?
As always, for the answers, one should ask the man -
man ssh. Something
I hadn’t done before for forwarding, mostly because I never needed to.
-L [...] Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given host and port, or Unix socket, on the remote side.
Having read the manual, I understand that essentially the
listens on the locally forwarded port and forwards the request to whatever
remote. Local requests to said port are forwarded to the remote!
So remote forwarding would be the exact opposite! Requests to a particular
port on the remote machine are being forwarded to a port on the local
machine. So that’s why I had to use
-R while fiddling with
git-clone a tag
I decided I wanted the github-pages Docker image - Alpine edition. GitHub does not publish it on their container registry; and making the PR to enable that was another yak to shave.
So instead I decided to clone the repo and build it on my machine. But I don’t want the whole history. I just need one tag!
At first I did a shallow clone using GitHub’s cli
gh repo clone github/pages-gem -- --depth=1
But I realised that doesn’t give the tags, and I needed a tag. Hmm
# in pages-gem repo git fetch --tags
Oh no, that’s all of them. I don’t want all of them
git tag -l | xargs git tag -d
Now I couldn’t figure out how to disable it from fetching tags, so I just deleted the repo. Trying to shave fewer yaks.
Then I got to thinking, what if I cloned just one tag? After some quick googling, I found the solution
gh repo clone github/pages-gem -- -b v221 --depth=1
git-clone -b could take a tag as an argument. Who knew?