Pin check/renovate back to brick-build now that its image has Node

The runner's label-to-image mapping got repointed at Gitea's own
official runner image (docker.gitea.com/runner-images:ubuntu-latest,
has Node out of the box) — the earlier opensuse/leap:16.0 mapping for
brick-build specifically was what broke check/renovate on 2026-09-12,
not brick-build the label itself. Back to pinning both to this
machine specifically instead of whichever runner answers to the
shared ubuntu-latest label.

.gitea/workflows/ci.yml

@@ -6,15 +6,14 @@ on:
 
 jobs:
   check:
-    # Not brick-build: that label's job container (opensuse/leap:16.0) has
+    # brick-build's job container now points at Gitea's own official
-    # no Node.js, and every step below (checkout, setup-ruby, setup-node)
+    # runner image (docker.gitea.com/runner-images:ubuntu-latest, has
-    # is a JS-based Action that needs it to even start — see the run that
+    # Node out of the box) — the earlier opensuse/leap:16.0 image that
-    # failed immediately on 2026-09-12. ubuntu-latest is shared with
+    # failed here on 2026-09-12 (no Node, every step below is a JS-based
-    # "Gitea Runner on Cube" too (not pinned to this machine specifically),
+    # Action) got repointed. Pinned to brick specifically again, rather
-    # but that's fine here: only deploy (runs-on: brick-host, a unique
+    # than the shared ubuntu-latest label "Gitea Runner on Cube" also
-    # label held by just the native runner on brick) actually needs to
+    # answers to.
-    # land on a specific box.
+    runs-on: brick-build
-    runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
 

.gitea/workflows/renovate.yml

@@ -9,8 +9,9 @@ on:
 jobs:
   renovate:
     # Same reasoning as check's runs-on in ci.yml: brick-build's job
-    # container has no Node, which setup-node/npm below need.
+    # container now has Node (repointed at Gitea's own official runner
-    runs-on: ubuntu-latest
+    # image), which setup-node/npm below need.
+    runs-on: brick-build
     steps:
       - name: Setup Node
         uses: actions/setup-node@v4

docs/deployment.adoc

@@ -7,16 +7,19 @@ MapTool deploys as a Podman container (via `podman compose`, driven by a
 the Gitea Actions runners run on. Two separate runners are registered
 against the Gitea instance:
 
-* The existing Docker-based runner (`gitea/runner:3`), labels
+* The existing Docker-based runner (`gitea/runner:3`), label
-  `ubuntu-latest`/`ubuntu-24.04`/`ubuntu-22.04` — runs the `check` and
+  `brick-build` — runs the `check` and `renovate` jobs in a fresh,
-  `renovate` jobs in a fresh, isolated container per job, same as
+  isolated container per job. Every label on this runner (including
-  before. It's also registered under `brick-build`, but that label's
+  `ubuntu-latest`/`ubuntu-24.04`/`ubuntu-22.04`, still registered but no
-  job container (`opensuse/leap:16.0`) has no Node.js, which every step
+  longer what `check`/`renovate` pin to) now maps to Gitea's own
-  in `check`/`renovate` needs (they're JS-based Actions) — until that
+  official runner image (`docker.gitea.com/runner-images:ubuntu-latest`,
-  image gets Node, or the label points elsewhere, `check`/`renovate`
+  has Node out of the box) — an earlier `opensuse/leap:16.0` mapping for
-  stay on `ubuntu-latest`. That label is shared with "Gitea Runner on
+  `brick-build` specifically had no Node, which every step in
-  Cube" too, so a `check`/`renovate` run isn't pinned to this specific
+  `check`/`renovate` needs (they're JS-based Actions), and briefly broke
-  machine — harmless, since only `deploy` actually needs a specific box.
+  both jobs (2026-09-12) until reverted to the shared `ubuntu-latest`
+  label; now that the image itself is fixed, both are pinned back to
+  `brick-build` — this machine specifically, not whichever runner
+  happens to answer to the shared label (e.g. "Gitea Runner on Cube").
 * A dedicated native runner, installed directly on the host (no Docker
   around it), label `brick-host` — runs only the `deploy` job.