ci: run Build and Style on the release branches too

.github/workflows/build.yml

@@ -4,8 +4,9 @@ on:
   push:
     branches:
       - main
+      - "release/**"
   pull_request:
-    branches: ["main"]
+    branches: ["main", "release/**"]
 
 # Smoke-build SO3 with Infrabase (bitbake) inside the so3-env image. Both the
 # kernel (build.sh -x so3) and the user space (build.sh -x usr-so3, which also

.github/workflows/style.yml

@@ -8,9 +8,9 @@ concurrency:
 
 on:
   push:
-    branches: ["main"]
+    branches: ["main", "release/**"]
   pull_request:
-    branches: ["main"]
+    branches: ["main", "release/**"]
 
 jobs:
   formatting-check:

doc/source/release_process.rst

@@ -141,6 +141,20 @@ release (they drift silently otherwise):
   ``PREFERRED_VERSION_avz`` entries in ``build/conf/local.conf`` (see the
   ``v6.2.3`` bump for a template).
 
+Before tagging: check the CI
+***************************
+
+The ``Build`` workflow runs on ``main`` **and on every** ``release/**``
+**branch**, so the commit a tag will point at has always been built. Check it
+before tagging::
+
+   gh run list --workflow Build --branch release/v6.2
+
+Tagging a red commit is how ``v6.2.4`` shipped a tree that no fresh clone
+could build. ``build (virt32)`` and ``build (virt64)`` are required status
+checks on ``main`` for the same reason: merging on red stays possible for a
+maintainer, but never by accident.
+
 Rules of thumb
 **************