Lately I have been not excited about maintaining my site or adding new content to it. That was mainly because of the fact that maintaining domain names for my personal site is not something I want to do. The same goes for SSL certificates although I do have a pretty convenient system for updating them using the EFF's certbot.

TL;DR I want to be able to focus on my sites content over anything else.

This post will be covering the new setup I have in place. There are a few components in the way my site is now deployed.

1. Github Pages
2. Sourcehut
3. Lektor

All three of these components are interesting technologies in and of themselves but #2 is the one I will focus on the most in this post. It should be noted that #3 also made this setup much easier, as it contains a toolset meant for integrating to #1.

        +----------------------+
Step 6. |https://wgwz.github.io|
        +----------------------+
Step 5. |ghpages               |
        +----------------------+
Step 4. |https://builds.sr.ht  |
        +-------------------------------+
Step 3. |https://git.sr.ht/~wgwz/my-site|
        +----------------------+--------+
Step 2. |git commit && git push|
        +-------------+--------+
Step 1. |edit my-site/|
        +-------------+

The interesting stuff happens between steps 3, 4 and 5. The git repository contains a ".build.yml" file:

image: alpine/edge
secrets:
  - 1c7823a9-63c2-432e-adca-39371c08e665
  - 47845823-510e-4d5b-8016-544743c51470
packages:
  - python3-dev
  - libffi-dev
  - openssl-dev
sources:
  - git@git.sr.ht:~wgwz/my-site
tasks:
  - check-branch: | 
      cd my-site 
      if [ "$(git rev-parse master)" != "$(git rev-parse HEAD)" ]; then \
        complete-build; \
      fi
  - setup: |
      cd my-site
      pip3 install --user lektor
  - build: |
      cd my-site
      ~/.local/bin/lektor build
  - deploy: |
      cd my-site
      ~/.local/bin/lektor deploy --username=wgwz --password=$(cat ~/.gh_personal_access_token) ghpages
shell: false

Often times when I see configuration files like this I get quite nervous in the sense that I wonder how the file was created. Testing these files can be quite difficult. I want to emphasize that experience creating this file was quite pleasant. It's something you should just go and try for yourself on sourcehut. Basically you are given a simple text box and you can start from scratch and build up precisely the file you need. Furthermore you can ssh into a live instance of your build at each iteration. This is extremely helpful as you can take a look at what is going on in the file system at every step of the way. Another thing that I really appreciated was that there were very few quirks to the way that the container was structured in terms filesystem layouts and other linux stuff.

So with a bit of fancy footwork on the sourcehut side of things I can install my static site manager "lektor", store some secrets like ssh-keys or github access tokens and set up tasks that execute regular commands. Figuring out how to use secrets on sourcehut was quite straightforward as well. But something that I definitely will need to verify I am doing correctly and securely. I'm also certain that the way I am cat-ing my github personal access token in the build file is a bad practice.

At the end of the day my workflow for publishing new content on my website is to make edits locally, commit my changes locally and push them to my version control system. After that a build process gets fired off and within a few minutes my static site management tool "lektor" has force pushed updates to my ghpages using a personal access token.

Type, commit and push. Feels like a cool breeze on a hot day. :-)