Add new posts and customize theme

.gitignore

@@ -1,2 +1,3 @@
 public/*
 .*.swp
+.hugo_build.lock

.gitmodules

@@ -1,3 +0,0 @@
-[submodule "themes/anatole"]
-	path = themes/anatole
-	url = https://github.com/lxndrblz/anatole.git

config.toml

@@ -1,7 +1,7 @@
 baseURL = "http://www.thehellings.com/"
 languageCode = "en-us"
 title = "The Hellings"
-theme = "anatole"
+theme = "greg-anatole"
 enableEmoji = true
 enableRobotsTXT = true
 
@@ -20,6 +20,11 @@ pygmentsUseClasses = true
 profilePicture = "images/profile.jpg"
 readMore = true
 
+[taxonomies]
+  category = "categories"
+  series = "series"
+  tag = "tags"
+
 [menu]
 
   [[menu.main]]

content/posts/pinephone.md

@@ -2,6 +2,10 @@
 title: "Pinephone"
 date: 2021-10-15T10:20:44-05:00
 draft: false
+tags:
+- technology
+- Linux
+- gadgets
 ---
 
 So I recently grabbed a [PinePhone](http://www.pine64.org/pinephone),

content/posts/what-is-ci.md

@@ -0,0 +1,75 @@
+---
+title: "What is CI?"
+date: 2022-01-26T22:58:17-06:00
+draft: false
+tags:
+- ci
+- continuous integration
+- ansible
+- software engineering
+- technology
+series:
+- Ansible CI
+---
+At work I have been doing CI for nearly 10 years, now. Having been working at Red Hat for
+the past 6 of those, some of the CI work that I do is available in open source contributions
+up on Git Hub. I plan to make a series of posts about that work, so I am going to start
+with this brief discussion of the very idea of CI before I get into working on the particular
+types of CI that I do.
+
+# CI is Not Automation
+
+OK, maybe I should go into a little bit more detail. CI is not automation.  At it's core,
+CI does not imply anything more than the two words in its name suggest. It is Continuous,
+and it is Integration. The "Continuous" part means that every step is integrated. Every
+branch as it comes into your version control gets integrated. Strictly speaking, every commit
+should be integrated, but as engineers we are willing to bend the rules and say that the
+integration needs to happen at the tip of a branch or a pull request. If you opt to squash
+merge a PR in git, then you can maintain that full coverage on your main branch.
+
+The second component of Continuous Integration is obvious the Integration portion. After we
+establish that every piece of the repository is integrated we need to discuss what the
+integration portion is. Integration comprises building candidate artifacts, testing, linting,
+reviewing, and preparing a candidate build for potential deployment.
+
+What you will notice is that, nowhere in the definition of Continuous Integration is it
+made mandatory that any or all portions be automated. It is perfectly acceptable to practice
+CI without any automation whatsoever. It might not be acceptable to someone holding the
+purse strings, but there is no technical reason you cannot run the process manually and
+still call it Continuous Integration. The only milestones you must hit to be considered
+CI is 1) Continuous and 2) Integration.
+
+# CI is Not Pushing Every Build
+
+That idea really falls under the umbrella of Continuous Deployment. Continuous Deployment
+itself is a companion idea to CI, but it is followed by every successful integration being
+deployed. Very few companies, projects, etc want to follow a strict Continuous Deployment
+strategy. However, one of the excellent benefits that CI gives is the ability to either
+utilize CD or at least be always ready to deploy the latest artifacts should the need or
+desire arise.
+
+CI is, in fact, attempting to be the backstop that allows a fast moving project to avoid
+breaking things as often as they otherwise might. If every candidate has been thoroughly
+vetted and is already prepared for deployment, then a project can employ a fast moving
+delivery schedule or a delivery-as-needed schedule with its confidence maximized by the
+process.
+
+Obviously, your confidence in your deployments can only be as good as your confidence in
+your verification process. If your project truly employes CI and is still seeing a high
+rate of failures on delivery, then your verification process could proably benefit from
+some improvements. One of the benefits of CI is that it can be a part of a rapid feedback
+cycle that improves the quality of processes - both of the software itself and of the
+validation process that a product undergoes.
+
+# But what about automation...
+
+Although CI does not demand automation, the names of the two have become nearly synonymous,
+as process and product complexity can rapidly grow beyond the abilities of manual testing,
+build, delivery, and other types of teams. This is where automation begins to earn its
+keep. A good build server configuration can produce artifacts far more quickly than waiting
+for manual builds to complete. A proper lint tool can find, report, and even fix problems
+far more quickly than a manual reviewer. A code formatting tool can produce standards-conformant
+code much more efficiently than a codebase audit can do. And, of course, a properly written
+set of automated tests can improve the confidence in a potential release artifact. Well
+written automation can find large numbers of defects much more rapidly than manual testing
+and can allow the goal of truly continuous integration to be achieved much more readily.

serve.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+podman run --rm -it -v $(pwd):/src -p 1313:1313 klakegg/hugo:latest server