Add git hook to check Markdown format of changed files (#275)

* Test commit to check git hook

* Add git hook for the Markdown format checking

* Improve git hook to detect changed by not yet commited files

* Fix Markdown formatting

Author: stefaniuk

.editorconfig

@@ -7,3 +7,6 @@ indent_size = 2
 indent_style = space
 insert_final_newline = true
 trim_trailing_whitespace = true
+
+[*{.mk,Makefile}]
+indent_style = tab

.github/workflows/markdown-check-format.yml

@@ -14,11 +14,6 @@ jobs:
       - uses: actions/checkout@v3
         with:
           fetch-depth: 0
-      # Please, make sure to enable Markdown linting in your IDE. For the Visual Studio Code editor it is
-      # `davidanson.vscode-markdownlint` that is already specified in the `.vscode/extensions.json` file.
       - run: |
-          files=$(git diff --diff-filter=ACMRT --name-only origin/${{ github.event.repository.default_branch }}.. "*.md")
-          if [ -n "$files" ]; then
-            image=ghcr.io/igorshubovych/markdownlint-cli@sha256:c902fc97bb4ba50cd073408e664fe00414e6e2064f0c213bafd393ea17f3a0fd # v0.32.1
-            docker run --rm -v $PWD:/workdir $image $files --disable MD013 MD033
-          fi
+          BRANCH_NAME=${{ github.event.repository.default_branch }}
+          scripts/markdown-check-format.sh

Makefile

@@ -0,0 +1,5 @@
+config: githooks
+
+githooks:
+	echo "scripts/markdown-check-format.sh" > .git/hooks/pre-commit
+	chmod +x .git/hooks/pre-commit

patterns/architect-for-flow.md

@@ -15,12 +15,14 @@ One key consideration is how best to break the system down into independent serv
 ## Benefits
 
 In high level terms, systems which are designed to maximise rapid, reliable delivery and operations:
+
 * Are cost efficient: teams don't waste their time fighting the tools or working with difficult architectures
 * Improve business agility: these systems allow teams to respond more quickly to changes
 * Improve reliability: these systems are easier to understand, which leads to fewer failures and shorter recovery times
 * Improve team happiness: engineers are happy when the tools they work with let them get on with what they do best
 
 In many cases, building a system as a set of independently running services/components has benefits:
+
 * Multiple components enable parallel development work by multiple teams
 * Teams can work at their own cadence
 * Changes with each component are easier to reason about and test
@@ -35,10 +37,10 @@ In many cases, building a system as a set of independently running services/comp
 
 * This pattern must not compromise quality: automation (including of quality control) is essential for safe implementation of this pattern
 * Architectures with multiple moving parts are more complicated. While splitting a system into multiple components is often a good idea, "too many" components can cause more harm than good. There is usually a sweet spot for how many components to break a system down into — and for small or simple systems a monolith might be better. In distributed systems:
-    * There are more failure modes to test, since calls which go over the network can fail in more ways than simple method invocations
-    * Versioning becomes a more complicated concern, and additional effort is required to ensure component APIs are compatible as each changes independently
-    * Clean domain boundaries are essential for safe implementation of this pattern
-    * Comprehensive monitoring and alerting is essential for safe implementation of this pattern
+  * There are more failure modes to test, since calls which go over the network can fail in more ways than simple method invocations
+  * Versioning becomes a more complicated concern, and additional effort is required to ensure component APIs are compatible as each changes independently
+  * Clean domain boundaries are essential for safe implementation of this pattern
+  * Comprehensive monitoring and alerting is essential for safe implementation of this pattern
 * Components should be built because working in that way gives benefits, not purely because the components might be reused later: if they are later reused, that's even better
 
 ## Details

scripts/markdown-check-format.sh

@@ -0,0 +1,22 @@
+#!/bin/bash
+
+# Check Markdown formating of all the "*.md" files that are changed and commited to the current branch.
+#
+# Usage:
+#   $ [options] ./markdown-check-format.sh
+#
+# Options:
+#   BRANCH_NAME=other-branch-than-main  # Branch to compare with
+
+# Please, make sure to enable Markdown linting in your IDE. For the Visual Studio Code editor it is
+# `davidanson.vscode-markdownlint` that is already specified in the `.vscode/extensions.json` file.
+
+files=$((git diff --diff-filter=ACMRT --name-only origin/${BRANCH_NAME:-main}.. "*.md"; git diff --name-only "*.md") | sort | uniq)
+if [ -n "$files" ]; then
+  image=ghcr.io/igorshubovych/markdownlint-cli@sha256:df7ce7cdcdb525d52a89d7aab17c507d49adceaddf2b767d3ed799c9537ded80 # v0.32.2
+  docker run --rm \
+    -v $PWD:/workdir \
+    $image \
+      $files \
+      --disable MD013 MD033
+fi