Overengineering this blog

Apr 22, 2023

Since I was added blogroll pages with RSS stuffs and reading about Tech news via lobste.rs and hckernews , It was gimme cool inspiration and care about simple things that can be works/done. Back then i was ever tweeted this:

https://nitter.it/i/status/1572990375962484736

Because of that tweet, make feel attacked want to write more about something that I personally maintain till now (aka this blog site). So in my current condition and perspective, it related to “it’s okay to not know everything” or something higher condition level is “just enjoy the process”.

(Enough, let’s continue technically ways!)

What i have done

Tweaking stuffs

Multistage Dockerfile

Split with common name build and runtime. No deep technical reason behind this but I guess Multistage it’s already common used and standard to keep minimize container size :))

# Build Mode
FROM node:${NODE_VERSION}-alpine${ALPINE_VERSION} as builder

# Download and install hugo
RUN wget -O - https://github.com/gohugoio/hugo/releases/download/v${VERSION}/hugo_${VERSION}_Linux-64bit.tar.gz | tar -xz -C /tmp \
    ... \

# Do more stuffs

RUN npm install --production # god please 😐
RUN hugo --minify -b ${HUGO_BASE_URL} --environment production

# Runtime Mode
FROM nginxinc/nginx-unprivileged:${NGINX_VERSION}-alpine # IYKYK 😉
COPY --from=builder /usr/share/blog/public /usr/share/nginx/html

# Do more stuffs

Repository structure

Currently, i dont’ have any idea about the technical reason for this case, but i just follow what common/current git(hub,lab) ways especially to place CI/CD config stores. But i have so curious about how to design or structure “monorepo” pattern.

Hail Makefile!

root_of_this_blog/
├── .gitlab/
│   ├── pipelines/
│   │   ├── docker-build.yml
│   │   └── docker-deploy.yml
│   └── ...
├── config/
│   └── nginx.conf
├── src/
│   ├── archetypes
│   └── content
├── .gitlab-ci.yml
├── Dockerfile
├── Makefile
└── README.MD

New CI/CD

This is what it looks like when adapt new repository structure and actually my ideas it’s split each stages then store it into .gitlab/ directory then call them with the include: keyword.

(This is nicely feature when you having many repository that adapt same condition stages or pattern => Tbh using this ways in my workplace)

stages:
  - test
  - build
  - deploy

include:
  - template: Security/Secret-Detection.gitlab-ci.yml
  - template: SAST.gitlab-ci.yml
  - '/.gitlab/pipelines/docker-build.yml'
  - '/.gitlab/pipelines/docker-deploy.yml'

variables:
  HUGO_BASE_URL: https://blog.riskiwah.xyz

build:
  extends: .build_container
  only:
    - master

deploy:
  extends: .deploy-ssh
  only:
    - master

Nginx tweak and better 404 page

Tweak about simple CDN (it’s not really distributed) usage. Can read it through A journey static assets web server: Part 1 .

---
title: Whoops! Page not found
noindex: true
layout: page
---
![](https://cdn.riskiwah.xyz/images/pulp-fiction.gif)

Shake up part

I hate .js but ok lah for this as long as we keep simple and keep small ¯\_(ツ)_/¯

Also this only happen if passed with env variable == production.

const purgecss = require('@fullhuman/postcss-purgecss')({
  content: ['./hugo_stats.json'],
  defaultExtractor: content => {
    const els = JSON.parse(content).htmlElements;
    return [
      ...(els.tags || []),
      ...(els.classes || []),
      ...(els.ids || []),
    ];
  },
  safelist: []
});

module.exports = {
  plugins: [
    ...(process.env.HUGO_ENVIRONMENT === 'production' ? [purgecss] : [])
  ]
};

Personally i dont know it’s working well or not and yeah below is the result after executing .js scripts.

Closing thought

Well this is my another weird writing about overengineering blog in addition to tech stuff's related, it’s good to me to explore more about platform base especially gitlab feature and generally what i got is keep learning while you busy on works 😂 😂 😂.

Sources

Thanks!