Logs of the creation of bitesyzedtechdiary


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.

Troubleshooting steps

I did what every self respecting dev does. I read the source code.

Ha ha.

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?

The Solution

So I shut everything down. Cleared the cached builds in the _site/ 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.

It was right there the entire time. It had not even occured to me! I had stared at the pages-gem’s dependencies on rubygems.org without having paid sufficient attention to the versions.

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.

Hunting for Jekyll docs corresponding to v3.9.0 I found the migration guide and now it made sense. And so I fixed it alll

Other discoveries

Using remote_theme locally

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 the plugins key in _config.yml does.

WAIT! So if adding a gem’s name to plugins enables it…

Fixing the RSS feed

  - 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’ 3.9.0

SSH’s Port Forwarding

never really made sense.

What was local, what was remote? How is 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.

man ssh

-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 ssh process 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 adb

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?