From 7d0eca78f2c392c341b38b856aee84da53a55000 Mon Sep 17 00:00:00 2001 From: Gregory Hellings Date: Wed, 26 Jan 2022 23:36:30 -0600 Subject: [PATCH] Add new posts and customize theme --- .gitignore | 1 + .gitmodules | 3 -- config.toml | 7 ++- content/posts/pinephone.md | 4 ++ content/posts/what-is-ci.md | 75 ++++++++++++++++++++++++++++++++ serve.sh | 2 + themes/{anatole => greg-anatole} | 0 7 files changed, 88 insertions(+), 4 deletions(-) create mode 100644 content/posts/what-is-ci.md create mode 100755 serve.sh rename themes/{anatole => greg-anatole} (100%) diff --git a/.gitignore b/.gitignore index 71e8b0b..26bd4cc 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ public/* .*.swp +.hugo_build.lock diff --git a/.gitmodules b/.gitmodules index b1b9af4..e69de29 100644 --- a/.gitmodules +++ b/.gitmodules @@ -1,3 +0,0 @@ -[submodule "themes/anatole"] - path = themes/anatole - url = https://github.com/lxndrblz/anatole.git diff --git a/config.toml b/config.toml index ecf5104..f1467d7 100644 --- a/config.toml +++ b/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]] diff --git a/content/posts/pinephone.md b/content/posts/pinephone.md index 6a3b9c7..2ce82a3 100644 --- a/content/posts/pinephone.md +++ b/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), diff --git a/content/posts/what-is-ci.md b/content/posts/what-is-ci.md new file mode 100644 index 0000000..db0c718 --- /dev/null +++ b/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. diff --git a/serve.sh b/serve.sh new file mode 100755 index 0000000..18a2634 --- /dev/null +++ b/serve.sh @@ -0,0 +1,2 @@ +#!/bin/bash +podman run --rm -it -v $(pwd):/src -p 1313:1313 klakegg/hugo:latest server diff --git a/themes/anatole b/themes/greg-anatole similarity index 100% rename from themes/anatole rename to themes/greg-anatole