Add instructions for resolving validation failures:

* Add instructions to the workflow at the point where the failure would
  occur, which is where someone experiencing a failure is most likely to
  look. To keep things simple, the instructions are always printed. The
  assumption is that if the job succeeds, nobody is likely to look
  anyway.
* Provides the diff of the failure as an artifact, so the user can apply
  it directly to their repo.
* Also update the levelization/README.md to clarify the levels a little
  bit.

.github/workflows/clang-format.yml

@@ -23,5 +23,38 @@ jobs:
     - name: Format src/test
       run: find src/test -type f \( -name '*.cpp' -o -name '*.h' -o -name '*.ipp' \) -print0 | xargs -0 clang-format-${CLANG_VERSION} -i
     - name: Check for differences
-      run: git diff --exit-code
+      id: assert
+      run: |
+        set -o pipefail
+        git diff --exit-code | tee "clang-format.patch"
+    - name: Upload patch
+      if: failure() && steps.assert.outcome == 'failure'
+      uses: actions/upload-artifact@v2
+      continue-on-error: true
+      with:
+        name: clang-format.patch
+        if-no-files-found: ignore
+        path: clang-format.patch
+    - name: What happened?
+      if: failure() && steps.assert.outcome == 'failure'
+      env:
+        PREAMBLE: |
+          If you are reading this, you are looking at a failed Github Actions
+          job.  That means you pushed one or more files that did not conform
+          to the formatting specified in .clang-format. That may be because
+          you neglected to run 'git clang-format' or 'clang-format' before
+          committing, or that your version of clang-format has an
+          incompatibility with the one on this
+          machine, which is:
+        SUGGESTION: |
 
+          To fix it, you can do one of two things:
+          1. Download and apply the patch generated as an artifact of this
+             job to your repo, commit, and push.
+          2. Run 'git-clang-format --extensions c,cpp,h,cxx,ipp develop'
+             in your repo, commit, and push.
+      run: |
+        echo "${PREAMBLE}"
+        clang-format-${CLANG_VERSION} --version
+        echo "${SUGGESTION}"
+        exit 1

.github/workflows/levelization.yml

@@ -12,7 +12,38 @@ jobs:
     - name: Check levelization
       run: Builds/levelization/levelization.sh
     - name: Check for differences
-      run: git diff --exit-code
-      # If this workflow fails, and you have improved levelization, run
-      # Builds/levelization/levelization.sh, and commit the changes to
-      # loops.txt.
+      id: assert
+      run: |
+        set -o pipefail
+        git diff --exit-code | tee "levelization.patch"
+    - name: Upload patch
+      if: failure() && steps.assert.outcome == 'failure'
+      uses: actions/upload-artifact@v2
+      continue-on-error: true
+      with:
+        name: levelization.patch
+        if-no-files-found: ignore
+        path: levelization.patch
+    - name: What happened?
+      if: failure() && steps.assert.outcome == 'failure'
+      env:
+        MESSAGE: |
+          If you are reading this, you are looking at a failed Github
+          Actions job. That means you changed the dependency relationships
+          between the modules in rippled. That may be an improvement or a
+          regression. This check doesn't judge.
+
+          A rule of thumb, though, is that if your changes caused
+          something to be removed from loops.txt, that's probably an
+          improvement. If something was added, it's probably a regression.
+
+          To fix it, you can do one of two things:
+          1. Download and apply the patch generated as an artifact of this
+             job to your repo, commit, and push.
+          2. Run './Builds/levelization/levelization.sh' in your repo,
+             commit, and push.
+
+          See Builds/levelization/README.md for more info.
+      run: |
+        echo "${MESSAGE}"
+        exit 1

Builds/levelization/README.md

@@ -16,10 +16,14 @@ reflect these rules. Whenever possible, developers should refactor any
 levelization violations they find (by moving files or individual
 classes). At the very least, don't make things worse.
 
-The table below summarizes the _desired_ division of modules. The levels
-are numbered from the bottom up with the lower level, lower numbered,
-more independent modules listed first, and the higher level, higher
-numbered modules with more dependencies listed later.
+The table below summarizes the _desired_ division of modules, based on the
+state of the rippled code when it was created. The levels are numbered from
+the bottom up with the lower level, lower numbered, more independent
+modules listed first, and the higher level, higher numbered modules with
+more dependencies listed later.
+
+**tl;dr:** The modules listed first are more independent than the modules
+listed later.
 
 | Level / Tier | Module(s)                                     |
 |--------------|-----------------------------------------------|