Being an emacs (specifically spcaemacs) user, I take most of my notes in org mode and prefer the workflow of org mode to markdown. It allows me to more easily get information out of my head, and organize it in a structured, easy to navigate format, not only on this site, but in plain text as well. However, docsify does not come with native org file support, so something had to be done.

find . -name \*.org -print0 | xargs -0 -I{} echo {} | sed 's/org//g' > files.txt
while read line; do
pandoc -s ${line}org -o ${line}md --to=markdown-fenced_code_attributes
done < ./files.txt is a simple script that takes all of the org files in the project, and converts them into markdown files of the same name. --to=markdown-fenced_code_attributes is included so that org-mode code blocks are converted into markdown code blocks that are compatible with docsify.js.

The build process takes place in Gitlab's CI/CD pipeline when creating the docker image.

FROM  jagregory/pandoc as builder
RUN mkdir /app
# Set the working directory to /music_service
# Copy the current directory contents into the container at /music_service
ADD . /app
RUN ls
RUN ./

FROM nginx
COPY --from=builder ./app/docs /usr/share/nginx/html

using an intermediate image to build the site and nginx to serve it makes sure that the final image size is small.

merges to the master branch triggers a deploy pipeline, which send my newly created docker image to my kubernetes cluster (which resides in my living room) with the tag name of the image being the short sha of the commit that triggered the build. This allows me to easily identify which commits are causing errors, and easy rollbacks to previously known working states.

I don't have the concept of tags creating deploys for this project simply because the idea behind this site is the ability to quickly add an update information to it, so that I have access to it anywhere.

Manual processes

as much as I would like to automate every proccess of updating this site, there are some manual processes left. Currently links on the sidebar must be manually added and removed, however, the formatting of the links is similar to the directory structure of the project, so one day may be expanded to create a generated _sidebar.html

project directory structure

rob@ThinkPad-T440s:~/ (pandoc)*
λ date
Mon Mar 25 03:06:35 CDT 2019
rob@ThinkPad-T440s:~/ (pandoc)*
λ tree
├── bookmarks
│   ├── images
│   │   ├── Grahams_Hierarchy_of_Disagreement.png
│   │   ├── is_it_worth_the_time.png
│   │   ├── service-reliablilty-heirarchy.jpg
│   │   └── what_graph_should_i_use.jpg
│   ├──
│   └──
├── docs
│   ├── quick-search
│   │   └──
│   └──
├── ergonomics
│   ├──
│   ├──
│   └──
├── index.html
├── meta
│   └──
├── nutrition
│   └──
├── quotes
│   ├──
│   ├──
│   ├──
│   └──
├── resume
│   └──
└── snippets
    ├── kubernetes
    │   ├──
    │   └── setup
    │       ├──
    │       ├──
    │       ├──
    │       ├──
    │       ├──
    │       ├──
    │       └──

12 directories, 37 files

- Bookmarks
  - [Links](bookmarks/links)
  - [Images](bookmarks/images)
- Documentation
  - [Quick Search](/docs/quick-search/)
- Ergonomics
  - [Emacs](/ergonomics/
  - [Keyboard Shortcuts](/ergonomics/
  - [Xset](/ergonomics/
- Snippets
  - Kubernetes
    - [Bare Metal Setup](/snippets/kubernetes/setup/)
      - [Initial](/snippets/kubernetes/setup/
      - [Master Node](/snippets/kubernetes/setup/
      - [Worker Node](/snippets/kubernetes/setup/
      - [Auto Complete](/snippets/kubernetes/setup/
      - [Deployments](/snippets/kubernetes/setup/
      - [Cleanup](/snippets/kubernetes/setup/
    - [Resource Definitions](/snippets/kubernetes/
  - [Electron](/snippets/
  - [LetsEncrypt](/snippets/
  - [OpenWrt](/snippets/
  - [Rails](/snippets/
  - [Networking](/snippets/
- Quotes
  - [Aleistor Crowley](/quotes/
  - [Marcus Aurelius](/quotes/
  - [Misc](/quotes/
- [Nutrition](/nutrition/)
- [Meta](/meta/)

There is not a set practice I have yet for laying out the order of links and directories yet, but `org-mode` supports custom properties which could be used to generate the order in which entries should be displayed.

local development and testing

previewing the site locally is done using docker-compose. Previously simply running an http server in the ./docs directory was sufficient, but the addition of has made it so that the site must be generated from org files to be previewed. Rather than running that command locally, and polluting my work space with generated markdown, docker-compose offers a seamless way to preview the site locally when making major changes. The image created from the docker-compose.yml is also an exact copy of my production environment, which allows greater confidence when making major changes.


version: '3.7'

    build: .
      - 8000:80

A setback to using this method is that I do not have the capability to hot reload on changes, and building the image takes many second when running docker-compose up --build (approx. 10 seconds on my laptop). Seeing changes also requires a full build to take place, since building the markdown happens in docker. Most changes to this site do not require physically viewing the site due to the generative nature, therefore revising this processes is a low priority.