Creation Log #002
Logs of the creation of bitesyzedtechdiary
EUREKA!
I had an archimedes moment.
As I ended
Creation Log #001
I was stuck. The theming did not work locally. And I had not been able to
figure out why. But under the influence of the shower, I realised I had
not imported the Minima styles in assets/main.scss
!
Creating the file and making the import should fix it!
I thought.
!EUREKA
That did not fix it. Not eureka.
github/pages-gem
Maybe I should just concede and use the GitHub Pages gem. But I still don’t have Ruby on my system, so the Docker image it is. Weird that they don’t publish the image. Let me fork and make my own- oh they do publish it ghcr.io/github/pages-gem.
Guess I’ll just pull- it was 1.08 GB?! Do they not build the alpine version??
I ended up digressing and trying to see if I could create a PR that built alpine images along with the regular, but GitHub Actions to me are waters murky still. FOCUS!
Oh. Even with the github-pages image, there are no styles.
layout: home
FINALLY! There was no layout defined. That was the real problem.
Settings a layout in the frontmatter of index.md
started rendering
the styles! Hurray!
I decided to set a default value for all posts in _config.yml
and that made it much better.
Dark theme
A dark theme is always pleasing to the eyes.
- me, now.
I wanted one for BSTD, but I
knew Minima did not have a dark theme in
the current latest stable release v2.5.1
.
Nonetheless, I did a quick Google search and found this lovely article by Tim Coobs, who happens to be using dark skin Minima for the very blog it’s posted on!
But of course copying that exactly over was not going to work. What works
locally doesn’t work on Github. And locally, GitHub’s abstractions are not
handled, even if I am using the github-pages
gem
so I can’t just use remote_theme
.
In the end we have a bodged setup at
22b572d
I also had to make a variety of changes to _config.yml
to match Minima’s
new data requirements.
Submodule regret
But before that, at
ccadf0d
I had converted _posts/
into a submodule. I knew I had experimented
with this before, but could not remember my results and conclusion. So I
went ahead with the conversion.
Well, I know now. Submodules are registered at a point in history. So even if luckily GitHub resolves and renders the content correctly, I need to commit on the gh-pages branch as well as the posts branch.
This is a facepalm moment.
But at least
It works and I managed to write three posts. (So much for calling it a diary)
In other news,
I made an open source contribution!
Context
Stalking around blog.slowb.ro, I discovered the author listed the entire stack they were employing for their blog. Time to use the pro-programmer move: stea- cough observe and gain inpsiration.
Thus I discovered Isso! A comment engine.
Isso is an informal, german abbreviation for “Ich schrei sonst!”, which can roughly be translated to “I’m yelling otherwise”. It usually ends the discussion without any further arguments.
Wanting to find one thing - one thing only - the databate used, I opened the documentation section. Found a typo. Skimmed through the rest of the documentation, didn’t reaaally find my answer. But the sample configuration led me to believe it would be SQLite.
Now, as I went go get the url, I see that it was on the homepage. As well as the FAQ section. Both of which I had clearly overlooked.
The bug
…was simple. An INI code block had a comment that wasn’t actually a
comment because of a missing ;
Quickly fixed it on the GitHub web interface, renamed the branch, opened a PR.
The maintainer asked for clarity in the commit message. I shouldn’t have been lazy.
The err
I did a shallow clone, as I usually do, and ammended the commit.
That was weird… I didn’t create anything. Why did the output list create mode? And zsh’s gitstatus looked even weirder… 1301 ↑ 1 ↓?
That can’t be right I told myself. But checking the logs I realised it was because the branch was grafted and dismissively just force pushed.
That force push broke the branch’s history and automatically closed the PR.
#TIL