freyjagp/blog.raer.me
1
0
Fork 0
Code Actions Packages Releases Activity

Add table of contents to old blogs

Browse Source
This commit is contained in:
Freyja Odinthrir
2024-09-27 13:56:48 -07:00
parent a93700b334
commit b357ab14b4
6 changed files with 70 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
content/2024/01/17/post-01.md
View File

@@ -2,7 +2,17 @@ Title: First blog post built with blag
Description: Because every new blog needs a new post.
Date: 2024-01-17 10:28
Tags: personal, gitops, devops, technical
Edited: 2024-01-18 00:18
Edited: 2024-09-27 13:50
# Table of Contents <!-- omit in toc -->
- [A new post for a new blog](#a-new-post-for-a-new-blog)
- [Fixing that old mess](#fixing-that-old-mess)
- [Static Site Generation](#static-site-generation)
- [Using blag](#using-blag)
- [Automation](#automation)
- [Conclusion](#conclusion)
# A new post for a new blog
@@ -14,13 +24,13 @@ Previously, <https://blog.raer.me/> was an html-only website. The pages were cre
That's terribly inconvenient. To boot, the thing wasn't version managed and it was deployed entirely manually directly to a folder on my reverse proxy server ([see more...](../../../2023/06/28/automating-some-things.md)) Yikes! None of this was ideal at all!
## Fixing that old mess
# Fixing that old mess
So building the blog with html manually was a pain in the ass. But doing something like an MVC framework or a CMS for a simple blog seemed like too much hassle as well. I don't want a WYSIWYG, or something that's browser-based. I hate dealing with browser frontends. Afterall, a blog is mostly - if not *entirely* - text-based. Why should I have to deal with the overhead of a server-side scripted website? I just want to write my blog in markdown - like i do with all my documentation already. Then I could even keep it in a git repo, backed up to my private gitea instance.
The answer to all of that, is `static site generation`. Turns out, there are plenty of other people out there who have looked at available tools, thought something similar to me, then built their own new tool that can take markdown, then generate a whole-ass website with it. Simple, and clean. You write content, maybe tweak some CSS/HTML templates, then the generator handles all the dirty work. No more searching for dozens of instances of a link when I change something in the navbar. That navbar is now a single template file that's reused by the generator.
## Static Site Generation
# Static Site Generation
This all sounds very complicated, yes? Well, sure. But really, its not.
@@ -187,6 +197,8 @@ jobs:
```
# Conclusion
Bear in mind, this all required a bit of setup and learning to self-host. But, when the hosts & runners are all set up and running properly, with the above workflow, updating this blog is a simple matter of committing to a git repo then pushing it to my remote. The runners handle everything else.
Ain't gitops grand?

15
content/2024/01/18/baja-tacos.md
View File

@@ -3,6 +3,21 @@ description: Some seafood tacos.
tags: cooking, recipes
date: 2024-01-19 05:59
# Table of Contents <!-- omit in toc -->
- [Baja Tacos](#baja-tacos)
- [Ingredients](#ingredients)
- [Fresh](#fresh)
- [Spices](#spices)
- [Protein](#protein)
- [Directions](#directions)
- [Prep](#prep)
- [Slaw](#slaw)
- [Sauce](#sauce)
- [Rub](#rub)
- [Assemble](#assemble)
# Baja Tacos
## Ingredients

10
content/2024/01/18/cheesecake-recipe.md
View File

@@ -2,6 +2,16 @@ title: Cheesecake
description: My birthday is soon, here's a cheesecake recipe.
tags: baking, cooking, cheesecake, recipes
date: 2024-01-18 12:05
edited: 2024-09-27 13:52
# Table of Contents <!-- omit in toc -->
- [New York style cheesecake](#new-york-style-cheesecake)
- [Ingredients](#ingredients)
- [For the Crust](#for-the-crust)
- [For the Filling](#for-the-filling)
- [Directions](#directions)
- [How to Slice Cheesecake](#how-to-slice-cheesecake)
# New York style cheesecake

11
content/2024/01/18/increasing-complexity.md
View File

@@ -2,6 +2,13 @@ title: Increasing complexity
description: A small issue snowballs because I want independence
tags: technical, gitops, devops
date: 2024-01-18 01:09
edited: 2024-09-27 13:52
# Table of Contents <!-- omit in toc -->
- [Increasing Complexity](#increasing-complexity)
- [Actually doing the thing](#actually-doing-the-thing)
- [Getting my fork on my package repo](#getting-my-fork-on-my-package-repo)
# Increasing Complexity
@@ -88,11 +95,11 @@ This isn't my first rodeo with setting these things up, though. I've got a simil
Okay. Enough talk, already! Lets do this!
## Actually doing the thing
# Actually doing the thing
So all that stuff I was talking about before was more-or-less me brainstorming what I needed to do. Here's some reporting back from me doing the stuff.
### Getting my fork on my package repo
## Getting my fork on my package repo
Turns out, the makefile is fine. Super easy. Just gotta hit it with a `make` command and its primo. So what I did, was I made the mirrors org and moved my blag mirror over there. Then I forked it to my personal gitea account. Then I cloned the fork, and made a `v2.3.0` branch because it was on `v2.2.x`. I updated the version in the source. Then I added the dependency for the new package `pymdown-extensions` in the appropriate files. Then I modified the `markdown.py` file to include the `footnotes` and `pymdownx.tilde` (strikethrough) extensions. Then I ran the makefile, which did its magic and made the stuff. Then I simply run twine to upload to my personal gitea package repo. Done. Version 2.3.0 is on my repo.