Merge pull request 'feat(ci): run the merge gate inside the CI-built toolbox image, pinned by digest' (#147 ) from feat/gate-toolbox-container into main

Reviewed-on: #147 Reviewed-by: Keith Jackson <[email protected]>
Merge pull request 'feat(gitea-actions): act_runner capacity 2, dind sized for two concurrent jobs' (#146 ) from feat/runner-capacity-2 into main
2026-11-08 06:51:00 +00:00 · 2026-11-08 06:47:05 +00:00 · 2026-11-08 06:45:31 +00:00 · 2026-11-08 06:37:13 +00:00 · 2026-11-08 00:26:27 -06:00 · 2026-11-08 00:25:45 -06:00
32 changed files with 945 additions and 67 deletions
@@ -165,7 +165,8 @@ Cost: the job shares the single act_runner slot with the gate, but the build its
  merge-gate.yaml            the pipeline (lint → l0 → l1 → conformance → decision)
  images.yaml                build/verify/publish this repo's container images (see above)
  scripts/
-    install-tools.sh         installs the pinned tools per stage (from ci/versions.env)
+    install-tools.sh         installs the pinned tools per stage (from ci/versions.env) — used by the
                             dormant merge-gate.yaml blueprint only; gate.yml runs in the toolbox image
    decide.sh                the R-TEST-03 merge decision over job results
    images.sh                the image pipeline's driver (what to build, base, push, digest)
  README.md                  this file
@@ -3,8 +3,10 @@
 # This is the LIVE gate wired to the in-cluster Gitea Actions runner (ns gitea-actions,
 # Docker executor + DinD). It invokes the AGGREGATE merge gate — `./ci/gate.sh`, which is
 # exactly what `make -C ci gate` runs, so CI and the devcontainer gate the same way
-# (R-TEST-02): the runner just installs the pinned tools from ci/versions.env first (and see
+# (R-TEST-02) — and since 2026-11-08 it runs INSIDE the same image: the job `container:` is the
-# below for why the script, not `make`, is invoked here). It runs every stage in order —
+# CI-built devcontainer toolbox (see "THE JOB IMAGE" below), not a generic runner image that
 # downloads the pinned tools on every run. (See further below for why the script, not `make`,
 # is invoked here.) It runs every stage in order —
 # spec-immutability, lint, Kyverno L0, render==golden, L1 offline render — and then applies the
 # R-TEST-03 decision, printing
 # "MERGE GATE: PASS" (0) / "BLOCKED" (1) / "UNDETERMINED" (3) / "NOT APPLICABLE" (0). It is the
@@ -17,7 +19,8 @@
 # kinds of non-run must be told apart HERE, in the caller, because only the caller knows which
 # environment it is:
 #   * a pinned tool missing or a seam unwired ON THIS RUNNER is a DEFECT — the toolchain is
-#     installed for us two steps up. GATE_STRICT_SKIPS=true DECLARES that (no env sniffing, no
+#     baked into the job image and checked against ci/versions.env two steps up.
 #     GATE_STRICT_SKIPS=true DECLARES that (no env sniffing, no
 #     "does this look like CI?" heuristic) and makes those skips exit 1: untolerated, job fails.
 #   * spec-immutability CANNOT be verified here at all: the spec repo is a separate repo and is
 #     not checked out into this runner (SPEC_REPO_SLUG unwired; blueprint in merge-gate.yaml). It
@@ -41,6 +44,32 @@
 # same script the laptop runs; the extra pre-step is a read-only git-diff check and is
 # purely additive. The full pipeline blueprint (spec-checkout, per-layer jobs, decision job)
 # is retained dormant in merge-gate.yaml.
 #
 # THE JOB IMAGE (2026-11-08, feat/gate-toolbox-container). The gate job runs in
 # gitea.home.keithjackson.dev/home-network/toolbox, pinned BY DIGEST — the image
 # .gitea/workflows/images.yaml builds from infra/devcontainer/Containerfile, verifies, and
 # publishes. It is the SAME image `infra/devcontainer/dev.sh` runs, so a local gate and the CI
 # gate now execute the identical toolchain (R-TEST-02), not two installs that agree by intent.
 # Before this, the job ran in ghcr.io/catthehacker/ubuntu:act-22.04 and spent ~11s of every run
 # re-downloading yamllint, check-jsonschema, kyverno, promtool and chainsaw
 # (.gitea/workflows/scripts/install-tools.sh l0 + l1; measured on runs 494/495).
 #   * PINNED BY DIGEST, MOVED BY RENOVATE. The `# renovate-digest:` marker above the image line
 #     is the repo-wide convention (renovate.json5, "This repo's own CI-published images"):
 #     Renovate follows the `main` tag and opens a digest-bump PR, whose OWN gate run then
 #     executes on the new image — the bump tests itself. infra/gitea/registry-retention.sh reads
 #     the same marker, so the pinned digest is never pruned. Never hand-edit it to a tag.
 #   * PULL AUTH: none needed. The Home-Network org is public and the registry issues an
 #     anonymous pull token (measured 2026-11-08: anonymous /v2/token -> manifest 200), so the
 #     runner's DinD pulls it like any public image. If the org is ever made private, add
 #     `credentials:` here with a read:package token secret — the automatic Actions token has no
 #     package scope at /v2/token (see images.yaml's header).
 #   * COLD PULL: ~467 MB compressed (1.54 GB unpacked). The DinD store is an emptyDir, so the
 #     first job after a runner-pod restart or a digest bump pays one pull; every other run finds
 #     it cached (forcePull=false), exactly as it already did for the catthehacker image.
 #   * NO NODE in the toolbox, so `actions/checkout` (a Node action) cannot run here. The checkout
 #     step is plain git instead — see its comment for how it keeps fetch-depth-0 semantics.
 #   * install-tools.sh is NOT deleted: merge-gate.yaml (the dormant blueprint) still calls it,
 #     and conformance/tests/l0-static/alert-rules-unit-tested asserts its promtool wiring.
 ---
 name: gate
@@ -78,16 +107,76 @@ jobs:
  # Single required status check: the static merge gate.
  gate:
    runs-on: ubuntu-latest
    # The CI-built toolbox — the same image dev.sh runs. See "THE JOB IMAGE" in the header.
    container:
      # renovate-digest: image=gitea.home.keithjackson.dev/home-network/toolbox tag=main
      image: gitea.home.keithjackson.dev/home-network/toolbox@sha256:83a3501efe34fa0b039e3f0d360738686a0f59109866c49779768f5d5ed0ef81
    steps:
-      - name: Checkout
+      # Plain git, because actions/checkout is a Node action and the toolbox has no Node. It
-        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      # reproduces what actions/checkout@v7 with `fetch-depth: 0` did here (read from its logged
-        with:
+      # commands on runs 490/495): full history of every branch + tags, so
-          fetch-depth: 0        # full history so ci/touched-requirements.sh can diff vs main
+      # ci/touched-requirements.sh can diff against origin/<base>; the exact event commit
-
+      # checked out (detached for a PR, as `-B <branch>` for a push). One difference, on
-      - name: Install pinned CI toolchain (ci/versions.env)
+      # purpose: the job token is passed to the single fetch through GIT_CONFIG_* environment
      # variables and is NOT persisted into .git/config — nothing after this step needs
      # authenticated git (ci/ and conformance/ make no network git calls), so there is no
      # reason to leave a credential in the workspace for the gate's scripts to read.
      - name: Checkout (git, full history)
        env:
          GIT_TOKEN: ${{ github.token }}
          SERVER_URL: ${{ github.server_url }}
          REPOSITORY: ${{ github.repository }}
          SHA: ${{ github.sha }}
          REF: ${{ github.ref }}
        run: |
-          ./.gitea/workflows/scripts/install-tools.sh l0
+          set -euo pipefail
-          ./.gitea/workflows/scripts/install-tools.sh l1
+          # act runs steps with umask 0000, so without this every checked-out directory is
          # world-writable — and Ansible then IGNORES infra/ansible/ansible.cfg as a source
          # ("Ansible is being run in a world writable directory"), which made the L0 check
          # prod-baremetal-not-dev-surface fail on this PR's first CI run (run 500). The
          # toolbox has Ansible, so that check now drives it for real. 0022 = what a
          # workstation clone gets (reproduced locally: 0000 fails the check, 0022 passes).
          umask 0022
          git config --global --add safe.directory "$PWD"
          git init -q .
          git remote add origin "${SERVER_URL}/${REPOSITORY}"
          auth="$(printf 'x-access-token:%s' "$GIT_TOKEN" | base64 -w0)"
          GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=http.extraHeader \
          GIT_CONFIG_VALUE_0="AUTHORIZATION: basic ${auth}" \
            git -c protocol.version=2 fetch --quiet --no-tags --prune --no-recurse-submodules origin \
              '+refs/heads/*:refs/remotes/origin/*' '+refs/tags/*:refs/tags/*' \
              "+${SHA}:refs/remotes/checkout/head"
          unset auth GIT_TOKEN
          case "$REF" in
            refs/heads/*) git checkout -q --force -B "${REF#refs/heads/}" "$SHA" ;;
            *)            git checkout -q --force --detach "$SHA" ;;
          esac
          [ "$(git rev-parse HEAD)" = "$SHA" ] || { echo "::error::HEAD is not ${SHA}" >&2; exit 1; }
          echo "checked out $(git log -1 --format='%H %s') (ref ${REF}); $(git rev-list --count HEAD) commits of history"
      # The image is the toolchain, so prove it is the PINNED one before trusting it: every
      # *_VERSION in ci/versions.env must equal what the image recorded at build time
      # (/etc/dev-toolchain-versions, written by infra/devcontainer/Containerfile; its `verify`
      # stage already asserted the version-sensitive binaries report those pins). This replaces
      # the per-run install: a drifted toolbox fails HERE, naming the tool, instead of gating with
      # a different engine. ci/versions.env and infra/devcontainer/versions.env must move together.
      - name: Toolchain is the one ci/versions.env pins
        run: |
          set -euo pipefail
          . ci/versions.env
          drift=0
          for var in $(grep -oE '^[A-Z_]+_VERSION' ci/versions.env); do
            tool="$(printf '%s' "${var%_VERSION}" | tr 'A-Z_' 'a-z-')"
            want="${!var}"
            got="$(sed -n "s/^${tool}=//p" /etc/dev-toolchain-versions)"
            if [ "$got" = "$want" ]; then
              printf 'ok     %-18s %s\n' "$tool" "$want"
            else
              printf '::error::DRIFT  %s: ci/versions.env pins %s, the job image has %s\n' "$tool" "$want" "${got:-nothing}"
              drift=1
            fi
          done
          [ "$drift" -eq 0 ]
      # R-TEST-06: the spec is read-only to agents. An EXPLICIT early surfacing of the
      # spec-immutability check, so its result is a distinct, tolerant status line in the
@@ -78,7 +78,7 @@ spec:
    spec:
      containers:
      - name: gitea
-        image: gitea/gitea:1.27.3
+        image: gitea/gitea:28.3.0
        ports:
        - containerPort: 3000
        env:
@@ -89,14 +89,18 @@ spec:
            secretKeyRef:
              name: gitea-bootstrap
              key: secret-key
        - name: GITEA__server__DOMAIN
          value: gitea.${BASE_DOMAIN}
        - name: GITEA__server__ROOT_URL
          value: https://gitea.${BASE_DOMAIN}/
        - name: GITEA__actions__ENABLED
          value: 'true'
        - name: GITEA__actions__DEFAULT_ACTIONS_URL
          value: github
        - name: GITEA__actions__RUN_RETENTION_DAYS
          value: '400'
        - name: GITEA__security__EGRESS_MODE
          value: lax
        - name: GITEA__service__DISABLE_REGISTRATION
          value: 'true'
        - name: GITEA_ADMIN_USERNAME
          valueFrom:
            secretKeyRef:
@@ -85,7 +85,7 @@ spec:
        - name: config
          mountPath: /config
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -90,7 +90,7 @@ spec:
              - -c
              - "# Assert the declared adlists in gravity.db. Idempotent: steady state writes nothing and\n# does NOT run a gravity rebuild.\nset -u\nGRAVITY=/etc/pihole/gravity.db\n\n# THE DECLARED SET \u2014 one URL per line, the source of truth for what PiHole blocks.\n# To add a list: add a line here, commit, let Flux reconcile. Nothing else to do.\nDECLARED='https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts'\n\n# On a fresh PVC, FTL creates gravity.db a moment after the container starts. Wait, bounded,\n# and NEVER block or fail the start: a missing DB here must not crashloop DNS for the LAN.\ni=0\nwhile [ ! -s \"$GRAVITY\" ] && [ \"$i\" -lt 90 ]; do sleep 2; i=$(expr $i + 1); done\nif [ ! -s \"$GRAVITY\" ]; then\n  echo \"pihole-adlists: gravity.db absent after 180s - leaving adlists untouched\" >&2\n  exit 0\nfi\n\nsql() { pihole-FTL sqlite3 \"$GRAVITY\" \"$1\"; }\nCHANGED=0\n\n# 1) Every declared URL must be present AND enabled.\necho \"$DECLARED\" | while IFS= read -r url; do\n  [ -n \"$url\" ] || continue\n  printf '%s\\n' \"$url\"\ndone > /tmp/declared.txt\nwhile IFS= read -r url; do\n  [ -n \"$url\" ] || continue\n  # Single quotes inside a URL would break this SQL; adlist URLs do not contain them.\n  have=$(sql \"select count(*) from adlist where address='$url';\")\n  if [ \"$have\" = \"0\" ]; then\n    echo \"pihole-adlists: adding $url\"\n    sql \"insert into adlist (address,enabled,comment) values ('$url',1,'declared in catalog/pihole.yaml');\"\n    CHANGED=1\n  else\n    en=$(sql \"select enabled from adlist where address='$url';\")\n    if [ \"$en\" != \"1\" ]; then\n      echo \"pihole-adlists: re-enabling $url\"\n      sql \"update adlist set enabled=1 where address='$url';\"\n      CHANGED=1\n    fi\n  fi\ndone < /tmp/declared.txt\n\n# 2) Anything enabled in the DB but NOT declared gets disabled (never deleted - see above).\nsql \"select address from adlist where enabled=1;\" | while IFS= read -r addr; do\n  [ -n \"$addr\" ] || continue\n  if ! grep -qxF \"$addr\" /tmp/declared.txt; then\n    echo \"pihole-adlists: disabling undeclared $addr\"\n    sql \"update adlist set enabled=0 where address='$addr';\"\n    echo changed >> /tmp/adlist-changed\n  fi\ndone\n[ -s /tmp/adlist-changed ] && CHANGED=1\nrm -f /tmp/adlist-changed /tmp/declared.txt\n\n# 3) Rebuild gravity ONLY if the declared set actually moved.\nif [ \"$CHANGED\" = \"1\" ]; then\n  echo \"pihole-adlists: declared set changed - running gravity update\"\n  pihole -g || echo \"pihole-adlists: gravity update failed; existing gravity.db retained\" >&2\nelse\n  echo \"pihole-adlists: already matches the declared set - nothing to do\"\nfi\nexit 0\n"
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -156,7 +156,7 @@ spec:
                , \"[Preferences]\"\n\ndef matches(raw):\n    \"\"\"True iff the stored digest is one OUR password produces (salt is read from it).\"\"\"\n    v = raw.strip().strip('\"')\n    if v.startswith(\"@ByteArray(\") and v.endswith(\")\"):\n        v = v[len(\"@ByteArray(\"):-1]\n    try:\n        salt_b64, digest_b64 = v.split(\":\", 1)\n        salt = base64.b64decode(salt_b64, validate=True)\n        digest = base64.b64decode(digest_b64, validate=True)\n    except Exception:\n        return False\n    if not salt or not digest:\n        return False\n    return hmac.compare_digest(\n        hashlib.pbkdf2_hmac(\"sha512\", pw.encode(), salt, ITERATIONS, len(digest)), digest)\n\ntry:\n    lines = open(conf, encoding=\"utf-8\", errors=\"replace\").read().splitlines()\nexcept FileNotFoundError:\n    lines = []\n\ndef value_of(key):\n    for i, line in enumerate(lines):\n        if line.startswith(key + \"=\"):\n            return i, line.split(\"=\", 1)[1]\n    return -1, None\n\nui, uval = value_of(UKEY)\npi, pval = value_of(PKEY)\nif uval == user and pval is not None and matches(pval):\n    raise SystemExit(0)          # converged - leave the file (and its salt) alone\n\nsalt = os.urandom(SALT_LEN)\ndigest = hashlib.pbkdf2_hmac(\"sha512\", pw.encode(), salt, ITERATIONS, DIGEST_LEN)\nstored = base64.b64encode(salt).decode() + \":\" + base64.b64encode(digest).decode()\ndesired = [UKEY + \"=\" + user, PKEY + '=\"@ByteArray(' + stored + ')\"']\n\nout = [line for i, line in enumerate(lines) if i not in (ui, pi)]\nif SECTION in out:\n    at = out.index(SECTION) + 1\nelse:\n    if out and out[-1].strip():\n        out.append(\"\")\n    out.append(SECTION)\n    at = len(out)\nout[at:at] = desired\n\ntry:\n    os.makedirs(os.path.dirname(conf) or \".\", exist_ok=True)\n    tmp = conf + \".webui-cred.new\"\n    with open(tmp, \"w\", encoding=\"utf-8\") as fh:\n        fh.write(\"\\n\".join(out) + \"\\n\")\n        fh.flush()\n        os.fsync(fh.fileno())\n    # This hook runs as ROOT; the service runs as PUID:PGID. A root-owned 0600 conf would\n    # cost the app the ability to save its own settings, so carry the ownership over.\n    try:\n        st = os.stat(conf)\n        os.chown(tmp, st.st_uid, st.st_gid)\n        os.chmod(tmp, stat.S_IMODE(st.st_mode))\n    except FileNotFoundError:\n        os.chown(tmp, int(os.environ.get(\"PUID\", \"1000\")),\n                 int(os.environ.get(\"PGID\", \"1000\")))\n        os.chmod(tmp, 0o664)\n    os.replace(tmp, conf)        # atomic: the app never reads a half-written conf\nexcept OSError as exc:\n    sys.stderr.write(\"[qbt-webui-cred] cannot write %s: %s\\n\" % (conf, exc))\n    raise SystemExit(1)\nraise SystemExit(10)\nPY\n  rc=$?\n\n  if [ \"$rc\" = 0 ]; then\n    log \"conf already holds the durable credential for '$QBT_WEBUI_USERNAME' (no write)\"\n  elif [ \"$rc\" = 10 ]; then\n    log \"asserted WebUI Username + Password_PBKDF2 into $CONF\"\n    # postStart runs CONCURRENTLY with the s6 init chain, so qbittorrent-nox may ALREADY\n    # have read the old, credential-less conf and be serving a random temporary password.\n    # Restart the SUPERVISED SERVICE (not the pod) so it re-reads what was just written.\n    # Nothing to do when the service has not started yet - it will read the new file.\n    # Its own counter, NOT the shared `waited` API budget: sharing one counter is how the\n    # 2026-09-13 failure spent the entire verification budget before the first login and\n    # then fired attempts 2 and 3 with no wait left at all.\n    sv=0\n    while [ \"$sv\" -lt 60 ] && [ \"$(s6-svstat -u \"$SVC\" 2>/dev/null)\" != \"true\" ]; do\n      sv=$((sv + 1)); sleep 1\n    done\n    if [ \"$(s6-svstat -u \"$SVC\" 2>/dev/null)\" = \"true\" ]; then\n      log \"qbittorrent-nox was already running - restarting it to load the credential\"\n      s6-svc -r \"$SVC\" || log \"s6-svc -r failed (continuing to verify anyway)\"\n      sleep 3\n    fi\n  else\n    log \"FAILED to write the credential into $CONF (helper exit $rc). The WebUI will keep\" >&2\n    log \"minting a random password\
                \ every start and BOTH arrs will break. Fix and restart.\" >&2\n    exit 0\n  fi\n\n  # (3) GROUND TRUTH: the WebUI itself must accept it. Wait for the API to answer at ALL\n  #     (shared ~120s budget across attempts), then spend exactly ONE login per attempt -\n  #     at most 3 rejected logins, which stays under qBittorrent's default ban threshold.\n  #\n  # \"THE API NEVER ANSWERED\" IS A DIFFERENT FAULT FROM \"THE PASSWORD WAS REJECTED\", and\n  # conflating them is what made this hook lie once already (see the PORT comment). An\n  # unreachable WebUI is reported as unreachable, and the hook stops rather than spending\n  # its remaining login attempts to produce two more identical wrong diagnoses.\n  api_ok=0\n  while [ \"$waited\" -lt 120 ]; do\n    code=$(curl -s -o /dev/null -m 3 -w '%{http_code}' \"http://127.0.0.1:$PORT/\" 2>/dev/null)\n    if [ -n \"$code\" ] && [ \"$code\" != \"000\" ]; then api_ok=1; break; fi\n    waited=$((waited + 1)); sleep 1\n  done\n  if [ \"$api_ok\" != 1 ]; then\n    log \"the WebUI never answered on 127.0.0.1:$PORT within the wait budget, so the\" >&2\n    log \"credential in $CONF is UNVERIFIED. This is NOT a rejected password - it was\" >&2\n    log \"never submitted. Do not rotate the credential on the strength of this line.\" >&2\n    exit 0\n  fi\n  body=$(curl -sS -m 10 \\\n           --data-urlencode \"username=$QBT_WEBUI_USERNAME\" \\\n           --data-urlencode \"password=$QBT_WEBUI_PASSWORD\" \\\n           \"http://127.0.0.1:$PORT/api/v2/auth/login\" 2>/dev/null)\n  if [ \"$body\" = \"Ok.\" ]; then\n    log \"VERIFIED: the WebUI accepts the durable credential for '$QBT_WEBUI_USERNAME'\"\n    exit 0\n  fi\n  log \"WebUI rejected the durable credential (login said '$body')\" >&2\n  # A rejection when the conf was ALREADY converged (rc=0, nothing written) can only mean\n  # the running qbittorrent-nox is serving something it read from an EARLIER conf, so\n  # rewriting the same bytes on the next attempt would change nothing. The remedy is to\n  # make the process RE-READ the file, so restart the supervised service and let the next\n  # attempt re-verify. Without this the retry loop could never change its own outcome.\n  if [ \"$(s6-svstat -u \"$SVC\" 2>/dev/null)\" = \"true\" ]; then\n    log \"restarting qbittorrent-nox so it re-reads $CONF, then re-verifying\" >&2\n    s6-svc -r \"$SVC\" || log \"s6-svc -r failed (continuing to verify anyway)\" >&2\n    sleep 3\n  fi\ndone\n\nlog \"GAVE UP after $attempt attempts: the WebUI does not accept the credential from git.\" >&2\n# A postStart hook MUST exit 0 - a non-zero exit makes the kubelet KILL the container\n# (FailedPostStartHook -> CrashLoopBackOff), turning a credential fault into an outage.\n# Both failure paths above therefore log LOUDLY and exit 0; the `up` SLI still watches the\n# app, and the arrs' own download-client health check surfaces a broken credential.\nexit 0\n"
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -77,6 +77,42 @@ spec:
    requests:
      storage: 1Gi
 ---
 # act_runner config file — DELTAS ONLY. act_runner v0.6.1 LoadDefault()
 # (internal/pkg/config/config.go) unmarshals this file onto a ZERO Config and then fills every
 # unset field with the same default it uses when there is no file at all, so a file holding
 # only `runner.capacity` changes exactly that and nothing else. Do NOT paste in the output of
 # `act_runner generate-config`: that example is NOT the defaults. Its `runner.labels` would
 # OVERRIDE the registered labels in /data/.runner (daemon.go: config labels win when non-empty)
 # and repoint ubuntu-latest at a different job image; its `force_pull: true` differs from the
 # no-file default (false); and its sample `envs` would be injected into every job.
 #
 # Using a file also makes act_runner IGNORE the legacy GITEA_RUNNER_CAPACITY / _FILE /
 # _ENVIRON / _ENV_FILE / GITEA_DEBUG / GITEA_TRACE env vars (deprecated.go). None of them is
 # set on this Deployment; the GITEA_INSTANCE_URL / _REGISTRATION_TOKEN / _NAME / _LABELS env
 # below is consumed by the image's run.sh for registration, not by that legacy path.
 #
 # A ConfigMap edit alone does NOT restart the runner (it reads the file once at start). If a
 # future change touches ONLY this ConfigMap, also bump the Deployment's pod template (e.g. the
 # config-revision annotation below) or the new value stays inert until the next restart.
 apiVersion: v1
 kind: ConfigMap
 metadata:
  name: act-runner-config
  namespace: gitea-actions
  labels:
    app.kubernetes.io/name: act-runner
 data:
  config.yaml: |
    runner:
      # Two concurrent jobs (default 1). Measured 2026-11-08: queue wait ~1s normally, but
      # 29-759s whenever gate / images / renovate runs collide (run 472 waited 759s behind a
      # renovate burst). Both jobs share the ONE dind daemon below; act_runner names each job's
      # containers GITEA-ACTIONS-TASK-<task id> and creates a network per job, so they do not
      # collide. Workflow `concurrency:` groups are enforced by Gitea server-side and are
      # unaffected: gate.yml's gate-<ref> group still cancels a superseded run on the SAME ref,
      # and renovate's group still serialises renovate. The dind resources are sized for TWO jobs.
      capacity: 2
 ---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
@@ -95,6 +131,10 @@ spec:
    metadata:
      labels:
        app.kubernetes.io/name: act-runner
      annotations:
        # Bump when act-runner-config changes without any other pod-template change, so the
        # Deployment rolls and act_runner re-reads its config (see the ConfigMap header).
        homelab.keithjackson.dev/act-runner-config-revision: "1"   # capacity 2
    spec:
      # CI holds no cluster credentials — do not mount a SA token into the runner or
      # (via the shared netns) the job containers (R-SEC-02, docs/14).
@@ -146,12 +186,23 @@ spec:
              mountPath: /certs
            - name: dind-storage
              mountPath: /var/lib/docker
          # Sized for runner.capacity: 2. Every job's containers run UNDER this daemon, so this
          # container's cgroup carries the whole CI workload. Measured 2026-11-08 (Prometheus,
          # capacity 1): peak CPU 0.69 core (1m rate, 30d), peak working set 447Mi (30d), 0 OOMs.
          #   cpu request 2: two jobs at today's peak is ~1.4 core, and the gate is being
          #     parallelised, so per-job demand rises. The request is what the CFS share is
          #     weighted by under contention (100m was a 1/20 share); NO cpu limit, deliberately,
          #     so an idle node's spare cores are still usable. k3s-prod-2 (8 CPU) had 2945m
          #     requested; +1.9 core = ~4.85 (61%), and prod-1/prod-3 fit too if it reschedules.
          #   memory request 1Gi / limit 4Gi: two jobs at today's peak is ~0.9Gi. An OOM kill here
          #     takes down dockerd and with it BOTH running jobs, so the limit carries ~4x headroom
          #     over that for the parallelised gate. Nodes have ~31Gi allocatable.
          resources:
            requests:
-              cpu: 100m
+              cpu: "2"
-              memory: 256Mi
+              memory: 1Gi
            limits:
-              memory: 2Gi
+              memory: 4Gi
          startupProbe:
            exec:
              command:
@@ -195,23 +246,36 @@ spec:
              value: /certs/client
            - name: DOCKER_TLS_VERIFY
              value: "1"
            # The image's run.sh passes `--config <this>` to BOTH `act_runner register` and
            # `act_runner daemon` when CONFIG_FILE is set (act_runner v0.6.1 scripts/run.sh).
            - name: CONFIG_FILE
              value: /etc/act_runner/config.yaml
          volumeMounts:
            - name: data
              mountPath: /data
            - name: certs
              mountPath: /certs
              readOnly: true
            - name: config
              mountPath: /etc/act_runner
              readOnly: true
          # Measured 2026-11-08 at capacity 1: peak CPU 0.24 core, peak working set 314Mi (30d)
          # against the old 512Mi limit. It holds per-task state, log buffers and the embedded
          # actions/cache server for every concurrent task, so the limit is doubled for capacity 2.
          resources:
            requests:
              cpu: 100m
-              memory: 128Mi
+              memory: 256Mi
            limits:
-              memory: 512Mi
+              memory: 1Gi
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: act-runner-data
        - name: certs
          emptyDir: {}
        - name: config
          configMap:
            name: act-runner-config
        - name: dind-storage
          emptyDir: {}
@@ -138,7 +138,7 @@ spec:
        - name: media
          mountPath: /media
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -138,7 +138,7 @@ spec:
        - name: media
          mountPath: /media
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -10,7 +10,7 @@
 name: gitea
 kind: container
 source:
-  image: gitea/gitea:1.27.3     # pinned recent stable tag (R-UPD-01); update.range governs advancement
+  image: gitea/gitea:28.3.0     # pinned recent stable tag (R-UPD-01); update.range governs advancement
 # Headless-install bootstrap (formerly apps/gitea-bootstrap-patch.yaml; now first-class via the
 # ServiceDefinition env/envFrom/lifecycle fields, schema >=1.2.0). Gitea must come up INSTALLED
 # without the interactive web wizard and with a FIXED, persistent SECRET_KEY, so all of this is
@@ -23,14 +23,43 @@ env:
      secretKeyRef:
        name: gitea-bootstrap
        key: secret-key
-  - name: GITEA__server__DOMAIN              # correct public clone/redirect URLs for the TLS-terminated host
+  # ROOT_URL is the ONLY source of the instance domain since Gitea 28 (go-gitea/gitea#39400): [server]
-    value: gitea.${BASE_DOMAIN}
+  # DOMAIN is no longer read, and the SSH domain defaults from ROOT_URL too. GITEA__server__DOMAIN was
  # removed in the 28 upgrade; the stale DOMAIN line environment-to-ini already wrote into app.ini is
  # inert. Correct public clone/redirect URLs for the TLS-terminated host come from this one value.
  - name: GITEA__server__ROOT_URL
    value: https://gitea.${BASE_DOMAIN}/
  - name: GITEA__actions__ENABLED            # Phase 6 CI/CD: declared (not implicit upstream default) so the
    value: "true"                            # in-cluster act_runner (ns gitea-actions) registers against it
  - name: GITEA__actions__DEFAULT_ACTIONS_URL  # resolve `uses: <org>/<action>@ref` from github.com (cluster
    value: github                              # has internet egress; not air-gapped)
  # Gitea 28 added run retention (go-gitea/gitea#38855): completed runs, with their jobs, logs and
  # artifacts, are deleted by the cleanup_action_runs cron after RUN_RETENTION_DAYS. Upstream's default
  # (400) is kept but DECLARED, so the deletion horizon is visible here rather than implicit. The spec
  # repo states no CI-history retention requirement; 0 would mean keep forever.
  - name: GITEA__actions__RUN_RETENTION_DAYS
    value: "400"
  # Gitea 28 (go-gitea/gitea#39426) puts webhooks, the OAuth2 avatar fetch and OpenID 2.0 behind an
  # egress policy: in the default lax mode, PUBLIC targets are allowed and private/loopback/CGNAT
  # targets need an IP or CIDR entry in [security] ALLOWED_HOST_LIST (a hostname entry is NOT enough
  # for a private address). DECLARED lax with an EMPTY allow list, deliberately:
  #   * the Keycloak OIDC login source is NOT gated by it. In 28.3.0 the openidConnect provider is
  #     goth's, built with its default HTTP client (services/auth/source/oauth2/providers_openid.go);
  #     egress.NewSecurityPolicy is used only by routers/web/auth/oauth.go (avatar fetch, and
  #     [oauth2_client] UPDATE_AVATAR is off here) and modules/auth/openid (OpenID 2.0, unused).
  #     So keycloak.<domain> resolving to the private Gateway address in-cluster does not matter.
  #   * this instance has no webhooks and no mirrors (measured 2026-11-07), and 1.27 already refused
  #     private webhook targets by default, so nothing that worked before is newly denied.
  # Adding an entry here would only WIDEN the webhook SSRF surface. Add the narrowest CIDR (e.g. the
  # Gateway address /32) only if a real private webhook target appears.
  - name: GITEA__security__EGRESS_MODE
    value: lax
  # Gitea 28 (go-gitea/gitea#39400) disables LOCAL self-registration unless DISABLE_REGISTRATION is
  # explicitly false; 1.27 defaulted it open. Declared true: accounts arrive via Keycloak only.
  # OAuth2 auto-registration below is unaffected — routers/web/auth/oauth.go gates it on
  # ALLOW_ONLY_INTERNAL_REGISTRATION and ENABLE_AUTO_REGISTRATION, not on DISABLE_REGISTRATION.
  - name: GITEA__service__DISABLE_REGISTRATION
    value: "true"
  - name: GITEA_ADMIN_USERNAME               # break-glass local admin creds (consumed by the postStart hook)
    valueFrom:
      secretKeyRef:
@@ -233,9 +262,14 @@ auth:
  # recovery tools (docs/15 "Availability caveat"). No secret is embedded here.
 update:
  channel: stable               # R-UPD-01
-  range: ">=1.22.0 <2.0.0"      # stay on the 1.x stable line
+  range: ">=28.0.0 <29.0.0"     # Gitea dropped the "1." prefix at 28.0.0 (successor of 1.27); stay on 28.x
  cadence: "0 4 * * *"
-  autoRollbackOnFailedHealth: true   # R-UPD-03
+  # R-UPD-03. INERT FOR THIS SERVICE, and it must stay that way: this flag renders only an annotation
  # on a Flux ImagePolicy, and apps/ is rendered --no-image-automation (ci/render-golden.sh), so no
  # ImagePolicy exists and the Deployment (strategy Recreate) is never auto-reverted. That matters
  # because a Gitea upgrade (1.27 -> 28 included) MIGRATES THE SQLITE DB ONE-WAY: an image revert onto
  # a migrated DB is not a rollback. Roll Gitea back by RESTORING THE DATA PVC from its pre-upgrade backup.
  autoRollbackOnFailedHealth: true
 observability:
  metrics: true
  slis:
@@ -129,7 +129,7 @@ AUTH_MODES = ("oidc", "forward-auth", "native", "none")
 # the sidecar authenticates the browser against Keycloak (homelab realm, the app's auth.groups)
 # and only THEN proxies to the co-located app UI at http://127.0.0.1:<uiport>. The gate is IN
 # the data path (fail-closed: no valid session in an authorized group => no upstream; R-IDP-02).
-OAUTH2_PROXY_IMAGE = "quay.io/oauth2-proxy/oauth2-proxy:v7.8.1"
+OAUTH2_PROXY_IMAGE = "quay.io/oauth2-proxy/oauth2-proxy:v7.15.6"
 OAUTH2_PROXY_PORT = 4180
 KEYCLOAK_ISSUER = f"https://keycloak.{ZONE}/realms/homelab"
@@ -99,7 +99,7 @@ caller that must distinguish them invokes `./ci/gate.sh` directly.
 | stage | a skip there means | verdict |
 |---|---|---|
-| `lint`, `l0`, `render-golden`, `l1` | a **pinned tool is absent** or a **wired seam went unwired** — it *could not run* | **BLOCKED** under strict skips (a CI runner: the toolchain is installed for us by `.gitea/workflows/scripts/install-tools.sh`, so a skip is a defect); **UNDETERMINED** otherwise (a workstation missing a tool is a real local condition — still non-zero, still not a pass; the remedy is `infra/devcontainer/dev.sh`, which carries the pinned toolchain) |
+| `lint`, `l0`, `render-golden`, `l1` | a **pinned tool is absent** or a **wired seam went unwired** — it *could not run* | **BLOCKED** under strict skips (a CI runner: the toolchain is the job image — the CI-built toolbox, `.gitea/workflows/gate.yml` `container:` — so a skip is a defect); **UNDETERMINED** otherwise (a workstation missing a tool is a real local condition — still non-zero, still not a pass; the remedy is `infra/devcontainer/dev.sh`, which carries the pinned toolchain) |
 | `spec-immutability` (R-TEST-06) | the sibling spec repo is not checked out, so the spec **could not be verified** | **UNDETERMINED** — unverified is unverified. Deliberately *not* upgraded to BLOCKED by strict skips: the live runner does not check the spec repo out at all, so blocking would leave the only enforced status check permanently red for a reason no PR could clear. It is therefore the **one** skip whose non-answer a caller may knowingly tolerate, and `.gitea/workflows/gate.yml` does so in one visible line. `REQUIRE_SPEC_VERIFICATION=true` makes it a hard block once that checkout is wired. Locally: check the spec repo out beside this one, or set `SPEC_REPO` (`dev.sh` mounts a sibling automatically). |
 | `decisions-log` | **nothing** — this stage has no skip path. It reads only files in the tree under test and needs no tool and no cluster, so there is no environment in which it "could not run" | a reported skip is a **defect in the stage** and BLOCKS. The stage fails when the frozen `DECISIONS-LOG.md` is modified (which silently re-creates, for every *other* open branch, the tail-hunk conflict that made four of five PRs unmergeable on 2026-09-29) or when a `decisions/` entry is malformed. There is deliberately **no** `REQUIRE_DECISIONS_LOG` knob: a guard with an off switch is not a guard. See `decisions/README.md`. |
 | `conformance` (L2/L3) | `CLUSTER_AVAILABLE!=true` — the environment **declared** the capability absent (documented Phase-0 behaviour) | **does not deny a PASS**: a declared-inapplicable stage was never *supposed* to run. It is NAMED in the PASS headline and step summary, the touched requirements it would have covered are reported UNVERIFIED, and `REQUIRE_CLUSTER_TESTS=true` (Phase 1+) turns that into a block. A skip **despite** `CLUSTER_AVAILABLE=true` is a defect and BLOCKS. |
@@ -46,8 +46,8 @@
 # WHICH SKIPS BLOCK, AND WHY (per stage — a skip is not one thing):
 #
 #   lint / l0 / render-golden / l1   A skip here means a PINNED tool is absent or a wired
-#     seam went unwired. On a CI runner the pinned toolchain is installed for us by
+#     seam went unwired. On a CI runner the pinned toolchain is the job image itself (the
-#     .gitea/workflows/scripts/install-tools.sh, so a skip there is a DEFECT, not an
+#     CI-built toolbox, .gitea/workflows/gate.yml), so a skip there is a DEFECT, not an
 #     environment: it BLOCKS. On a workstation a missing tool is a real local condition, so
 #     it degrades to UNDETERMINED (still non-zero, still never a pass). See strict_skips()
 #     in ci/lib.sh for how CI is detected and why misdetecting it cannot fail open.
@@ -257,7 +257,7 @@ for s in lint l0 render-golden l1; do
    skip)
      if strict_skips; then
        err "${s}: skipped (unwired seam / missing tool) under STRICT skips, where the pinned"
-        err "  toolchain is installed for us (.gitea/workflows/scripts/install-tools.sh) and every"
+        err "  toolchain is baked into the job image (.gitea/workflows/gate.yml container:) and every"
        err "  seam is on main — so this is a DEFECT, not an environment -> blocks merge"
        summary "- ${s}: **SKIPPED under strict skips** (unwired seam / missing tool) — blocks merge"
        BLOCK=1
@@ -97,9 +97,9 @@ cluster_available() { truthy "${CLUSTER_AVAILABLE:-false}"; }
 # --- Skip strictness: is this a CI runner, or a workstation? -------------------
 # A SKIPPED stage is never green anywhere (HARD RULE 4), but its SEVERITY differs:
 #
-#   CI       the pinned toolchain is installed by .gitea/workflows/scripts/install-tools.sh
+#   CI       the pinned toolchain IS the job image (the CI-built toolbox; gate.yml `container:`),
-#            before the gate runs, and every seam is on `main`. A stage that skips here is a
+#            and every seam is on `main`. A stage that skips here is a
-#            DEFECT (a tool dropped from the installer, a seam that went unwired) -> BLOCK.
+#            DEFECT (a tool dropped from the image, a seam that went unwired) -> BLOCK.
 #   local    a missing pinned tool is a real, ordinary local condition -> the gate reports
 #            UNDETERMINED (exit 3): not green, not a pass, but distinguishable from a red.
 #
@@ -62,7 +62,7 @@ spec:
        ports:
        - containerPort: 8080
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -85,7 +85,7 @@ spec:
        - name: config
          mountPath: /data/config
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -85,7 +85,7 @@ spec:
        - name: config
          mountPath: /data/config
      - name: oauth2-proxy
-        image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+        image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
        imagePullPolicy: IfNotPresent
        args:
        - --http-address=0.0.0.0:4180
@@ -0,0 +1,62 @@
 ---
 date: 2026-11-07
 branch: feat/gitea-28
 title: "Gitea 1.27.3 -> 28.3.0 (upstream dropped the 1. prefix)"
 ---
 ## What changed
 - `catalog/gitea.yaml`: `source.image` `gitea/gitea:1.27.3` -> `gitea/gitea:28.3.0` (still the
  newest stable tag on Docker Hub and GitHub on 2026-11-07: 28.0.0, 28.1.0, 28.2.0, 28.3.0).
  `update.range` `">=1.22.0 <2.0.0"` -> `">=28.0.0 <29.0.0"`.
 - 28.x breaking changes handled in the env block:
  - `GITEA__server__DOMAIN` **removed**: 28 no longer reads `[server] DOMAIN` (go-gitea/gitea#39400);
    `ROOT_URL` was already set and is now the only source of the domain. Nothing else in the repo
    reads the variable (the bootstrap script sets ROOT_URL/SSH_PORT only).
  - `GITEA__actions__RUN_RETENTION_DAYS=400` **declared** (go-gitea/gitea#38855 added the 400-day
    default; the spec repo states no CI-history retention requirement).
  - `GITEA__security__EGRESS_MODE=lax` **declared, with no allow list.** Read from the 28.3.0
    source: the Keycloak OIDC login source does NOT go through the new egress policy (goth's
    openidConnect provider, default HTTP client). The policy covers webhooks, the OAuth2 avatar
    fetch (`UPDATE_AVATAR` is off) and OpenID 2.0. A hostname entry would not even help for a
    private address — `WithLocalNeedsIPAllow` requires an IP/CIDR entry. So the brief's
    "Keycloak SSO breaks" premise does not hold for 28.3.0, and an allow-list entry would only
    widen webhook SSRF reach.
  - `GITEA__service__DISABLE_REGISTRATION=true` **declared** (28's new default; 1.27 defaulted it
    open). OAuth2 auto-registration is gated separately and keeps working.
 - `update.autoRollbackOnFailedHealth`: kept `true`, commented as **inert**. It renders only an
  annotation on a Flux ImagePolicy, and `apps/` is rendered `--no-image-automation`, so no
  ImagePolicy exists. The Deployment is `Recreate` with no probes, so nothing reverts the image
  automatically. Rollback = restore the PVC, never an image revert onto the migrated DB.
 - `apps/wave-0/gitea.yaml` re-rendered with the canonical command
  (`render.py --all catalog -o apps --wave-layout --no-image-automation`, in the toolbox). Only
  gitea changed.
 - `renovate.json5`: gitea `allowedVersions` `<2.0.0` -> `<29.0.0`; the description no longer calls
  28.x a stale tag.
 ## What I verified
 - Docker Hub tag list and GitHub tags: 28.3.0 is the newest 28.x stable tag.
 - Read the v28.3.0 source: `modules/egress/policy/policy.go`, `modules/egress/policies.go`, every
  `egress.New*` caller, `services/auth/source/oauth2/providers_openid.go`,
  `modules/setting/{security,actions,service}.go`, `routers/web/auth/{oauth,linkaccount}.go`,
  `cmd/admin_user_list.go`, `cmd/admin_auth*.go`, the Dockerfile, and `docker/root` (the s6 setup
  still runs `environment-to-ini`). The postStart hook's CLI is unchanged in 28.3.0: `admin user
  list --admin` still has Username in column 2, `admin auth list` still has ID/Name in columns 1/2,
  `add-oauth`/`update-oauth` keep the same flags, and curl and su-exec are still in the image.
 - Live Gitea (API, 2026-11-07): version 1.27.3. Zero repo, org and system webhooks, no mirrors.
 - `renovate-config-validator` at 44.167.0 (the tag renovate.yaml pins): "Config validated
  successfully".
 - Ran the toolbox gate on the committed tree (numbers are in the PR).
 ## What I did NOT verify
 - **The upgrade itself.** Nothing booted 28.3.0 against a copy of the production DB. Migration
  time, migration success and the post-upgrade SSO login are all UNVERIFIED, and the PR's
  post-merge checklist covers them.
 - **The age of the latest gitea-data Longhorn/off-cluster backup.** The cluster read failed from
  the worktree (no k3s-prod context with the kubeconfig available), so the operator must confirm
  it before merging.
 - How the Envoy Gateway handles the new `/-/ws` WebSocket. If upgrades are not forwarded, live
  notifications fall back to polling (not breaking). UNVERIFIED.
 - Whether the L2/L3 conformance suite passes. It does not run in CI.
@@ -0,0 +1,104 @@
 ---
 date: 2026-11-08
 branch: feat/gate-toolbox-container
 title: The merge gate runs inside the CI-built toolbox image, pinned by digest — no per-run tool install
 ---
 ## What changed
 `.gitea/workflows/gate.yml`, job `gate` (job name, the gate step, its env and its
 `|| [ "$?" -eq 3 ]` tolerance are unchanged, so the required context `gate / gate (pull_request)`
 is unchanged):
 - **`container:`** `gitea.home.keithjackson.dev/home-network/toolbox@sha256:83a3501e…ef81` — the
  image `images.yaml` published from `dd94101` (run 789; it is today's `main` and `sha-dd941016478c`
  tag). The same image `infra/devcontainer/dev.sh` runs, so local and CI gate on the identical
  toolchain. A `# renovate-digest: image=… tag=main` marker sits on the line above, the repo's
  existing convention; `infra/gitea/registry-retention.sh` reads the same marker, so this digest
  is protected from pruning.
 - **`actions/checkout` replaced by a plain-git step.** The toolbox has no Node (measured:
  `command -v node` → missing), and `actions/checkout` is a Node action. Chosen over adding Node to
  the toolbox because that would need two sequential PRs (Containerfile, then a publish, then the
  pin) and would put a JS runtime into the operator toolbox only to run one action. The step
  reproduces what checkout@v7 `fetch-depth: 0` actually ran here (read from runs 490 and 495):
  every branch to `refs/remotes/origin/*`, tags, plus the event SHA; detached for a PR,
  `-B <branch>` for a push; asserts `HEAD == github.sha`. The job token goes to that one fetch via
  `GIT_CONFIG_*` env and is **not** persisted in `.git/config` (nothing later needs network git).
  It sets **`umask 0022`** first: the PR's first CI run (run 500) failed L0
  `prod-baremetal-not-dev-surface` because act runs steps with umask 0000, every checked-out
  directory was world-writable, and Ansible (present in the toolbox, absent from the catthehacker
  image) then ignored `infra/ansible/ansible.cfg`. Reproduced locally in the pinned image: clone
  under umask 0000 → that check fails with the same message; under 0022 → `check OK`. Side
  effect worth knowing: the Ansible-driven parts of that check now actually execute in CI.
 - **"Install pinned CI toolchain" step removed**, replaced by **"Toolchain is the one
  ci/versions.env pins"**: every `*_VERSION` in `ci/versions.env` must equal the image's
  `/etc/dev-toolchain-versions`, else `::error::DRIFT` and the job fails. Without this, dropping
  the installer would have made `ci/versions.env` an unenforced claim for everything except
  promtool (which `alert-rules-unit-tested` already asserts).
 - Header comments rewritten for the new job image (pull auth, cold-pull size, no-Node, why
  `install-tools.sh` stays).
 `renovate.json5`: the `renovate-digest` custom manager now also scans `.gitea/workflows/gate.yml`;
 the `github-actions` manager is disabled for this repo's own images (same reason the `kubernetes`
 manager already was: it would see a digest-only image and look up `latest`).
 Comment/message wording only: `ci/gate.sh` (header + the strict-skip error text), `ci/lib.sh`,
 `ci/README.md`, `.gitea/workflows/README.md` — they said the CI toolchain comes from
 `install-tools.sh`.
 `.gitea/workflows/scripts/install-tools.sh` is **kept**: `merge-gate.yaml` (dormant blueprint)
 calls it, and `conformance/tests/l0-static/alert-rules-unit-tested/check.sh` asserts its promtool
 wiring (not touched — another agent owns `conformance/`).
 **Consequence to know:** every toolbox digest bump is now a Renovate PR touching `.gitea/**`,
 i.e. a sensitive path needing an operator `/approve-override`. That is arguably correct (a new
 toolchain changes what green means — and `ci/versions.env` was already sensitive), but it is a
 new recurring operator touch.
 ## What I verified
 - Registry pull auth: the Home-Network org is `public`; anonymous `/v2/token` → manifest `200`,
  `docker-content-digest: sha256:83a3501e…ef81` for both `main` and `sha-dd941016478c`. So no
  `container: credentials:` is needed. (The Actions token could not have been used anyway — no
  package scope, per images.yaml's header.)
 - Image: 466,912,274 bytes compressed across 6 layers (manifest sum), 1,541,728,125 bytes
  unpacked (`podman image inspect`). Local cold pull 10.4s on the workstation.
 - Image tool versions equal `ci/versions.env` for all 8 pins (kyverno 1.19.0, kyverno-json 0.0.3,
  chainsaw 0.2.12, yamllint 1.35.1, kubectl 1.36.4, yq 4.44.6, promtool 3.14.0, check-jsonschema
  0.29.4) — both via `/etc/dev-toolchain-versions` and by running each binary's `--version`.
  `sleep`, `tail`, `git` 2.56.0, `bash`, `python3`, `jq`, `curl` present (act's entrypoint is
  `/bin/sleep 10800`).
 - The new checkout script, run in the pinned image against the public repo (auth header disabled
  for the test only): PR ref `refs/pull/143/head` → detached at `60e3a24`, 1018 commits; push ref
  `refs/heads/main` → `On branch main` at `e8d2666`; `origin/main` present in both. The
  toolchain-drift step passes on the real `ci/versions.env` and exits 1 naming both tools when
  yamllint/promtool pins are altered.
 - Renovate marker regex (copied from renovate.json5) matches gate.yml exactly once, capturing
  depName/tag/digest.
 - LOCAL GATE, run **in the pinned CI image itself** (`IMAGE=<the digest above>` through
  `dev.sh`, `DEV_KUBECONFIG=/dev/null`, ENGINE shim adding the main checkout's `.git` read-only),
  on commit `9537ca2`: **rc 3**; spec-immutability, decisions-log (78 entries), lint, l0,
  render-golden, l1, approval-policy (N/A locally — not a PR event) all pass; **gitea-settings
  the only stage not run** (no `SETTINGS_API_TOKEN` locally); L2/L3 conformance skipped as
  usual. rc 3 is not green.
 - **CI, this PR's own runs** (Gitea API `/actions/runs/{id}/jobs` + job logs):
  - run 500 (`514ed5d`, cold DinD cache: `Image exists? false`, image pulled): job 151s; set-up
    incl. pull **9s**, checkout <1s, toolchain check 1s (all 8 pins `ok`), gate 140s → BLOCKED by
    L0 `prod-baremetal-not-dev-surface` (umask, fixed above) + approval-policy.
  - run 503 (`27d603f`, warm: `Image exists? true`): job **140s**; set-up 1s, checkout 1s,
    toolchain check 0s, gate 137s. Every stage passes — l0 (incl. prod-baremetal-not-dev-surface),
    lint, decisions-log, render-golden, l1, **gitea-settings** — except **approval-policy**,
    the expected sensitive-path block. spec-immutability skipped (expected, no spec repo in CI).
  - baseline before (runs 494/495, push on main): job 180s/179s; set-up 1–2s, checkout 1s,
    **install 11s**, gate 164–165s. The install step is gone; the remaining ~25s gate-step delta
    is NOT claimed as caused by this change (different base commits, one sample each).
 - Re-gated locally on `27d603f` in the pinned image: rc 3, gitea-settings the only not-run stage.
 ## What I did NOT verify
 - Renovate actually opening a digest-bump PR for gate.yml — only the regex was tested, not a
  Renovate run.
 - Push-to-main behaviour in CI (only the PR event runs before merge).
 - Whether the gate-step speedup (165s → 137s) is real or run-to-run variance.
 - That the cold-pull cost stays ~9s under a busier node or a bigger digest delta; one sample.
@@ -0,0 +1,74 @@
 ---
 date: 2026-11-08
 branch: fix/keycloak-operator-crds
 title: "Keycloak 26.8.2 operator CrashLoop: install its two new CRDs, raise its memory"
 ---
 ## What changed
 **Incident.** PR #121 (Renovate) bumped `platform/keycloak/kustomization.yaml`'s three
 `keycloak-k8s-resources` URLs 26.0.6 -> 26.8.2. Upstream `kubernetes/` at 26.8.2 holds **four**
 CRDs, not two (GitHub contents API, `?ref=26.8.2`):
 | file | at 26.0.6 | at 26.8.2 |
 |---|---|---|
 | `keycloaks.k8s.keycloak.org-v1.yml` | yes | yes |
 | `keycloakrealmimports.k8s.keycloak.org-v1.yml` | yes | yes |
 | `keycloakoidcclients.k8s.keycloak.org-v1.yml` | — | **new** (v2alpha1) |
 | `keycloaksamlclients.k8s.keycloak.org-v1.yml` | — | **new** (v2alpha1) |
 | `kubernetes.yml` | yes | yes (now carries RBAC for both new kinds) |
 (`cluster-wide/` is a separate variant; upstream's own `kubernetes/kustomization.yml` lists exactly
 the five files above.) The 26.8.2 operator starts an informer for every controller it has and dies
 on the first missing kind: `Couldn't start informer for keycloaksamlclients.k8s.keycloak.org/v2alpha1
 ... GET .../namespaces/keycloak/keycloaksamlclients ... Not Found`, exit 1, CrashLoopBackOff. Flux
 `platform` (`wait: true`, 5m) sat in health checks and every dependent Kustomization reported
 `dependency ... is not ready`. The old 26.0.6 ReplicaSet kept serving (RollingUpdate 25%/25%), so SSO
 stayed up.
 **Fix.**
 - `platform/keycloak/kustomization.yaml`: added the two CRD URLs, each with the same
  `# renovate: datasource=github-tags depName=keycloak/keycloak-k8s-resources` marker (the repo's
  custom.regex manager matches all five — checked by running its regex over the file). Header
  comment updated to v26.8.2, plus a warning that Renovate cannot add a CRD a release introduces.
 - Same file: a `patches:` JSON6902 patch on Deployment `keycloak-operator`: memory limit
  450Mi -> **768Mi**, request 450Mi -> **512Mi**. 450Mi is upstream's default (unchanged at 26.8.2,
  so not something the bump changed). Evidence it is too small here: the 26.0.6 pod had **154
  restarts**, `lastState.terminated.reason: OOMKilled` (exit 137, 2026-11-07T23:09:54Z), and
  `kubectl top` showed **421Mi / 450Mi**. 26.8.2 runs four controllers instead of two on Quarkus
  3.40.1.1 (was 3.15.1). No variable in the operator to disable watching unused kinds was used —
  installing the CRDs is upstream's supported shape.
 - `platform/keycloak/README.md` "Upgrading Keycloak": the diff-the-CRD-list step; "three URLs" ->
  "the release URLs". `renovate.json5`: same wording fix in a comment only.
 ## What I verified
 - Upstream file lists at 26.0.6 and 26.8.2 (GitHub API) and `diff` of `kubernetes.yml` between the
  two: the new kinds' ClusterRoles + RoleBindings ship in it, and the Deployment's resources are
  still 450Mi/450Mi.
 - Live, read-only (`kubectl --context k3s-prod`, 2026-11-08 ~05:57Z): only `keycloaks` and
  `keycloakrealmimports` CRDs installed; Deployment strategy RollingUpdate maxSurge/maxUnavailable
  25%; RS `keycloak-operator-58dff6c4` (26.8.2) 0/1 CrashLoopBackOff, RS `78dbb75f64` (26.0.6) 1/1;
  operator log is the informer error above; Flux `platform` `Healthy=Unknown` "Running health
  checks for revision main@sha1:e8d2666"; no NetworkPolicy and no CiliumNetworkPolicy in ns
  `keycloak`.
 - No sensitive path touched (`infra/gitea/approval-policy.json`), so this should merge on green.
 - Gate: see the PR body for the exact rc and stages of the run against the final commit.
 ## What I did NOT verify
 - **That the 26.8.2 operator becomes Ready after this merges.** Only the two missing kinds were
  observed failing; another start-up failure behind them is possible.
 - **That 768Mi is enough** — no 26.8.2 memory measurement exists yet; re-check `kubectl top` after
  a week.
 - **The Keycloak server upgrade 26.0.6 -> 26.8.2 itself.** Once the operator runs it will roll
  keycloak-0/1 and Keycloak migrates the DB schema. The CR's `spec.update.strategy` defaults to
  `RecreateOnImageChange` — expect a **full SSO outage** while both pods recreate, not a rolling
  one. Back up / confirm the latest CNPG backup first if that matters.
 - **The 26.8.2 Keycloak CRD's `spec.networkPolicy.enabled` defaults to `true`.** The operator will
  create a NetworkPolicy selecting the Keycloak pods (first policy in that namespace). With no
  `from` lists set it allows all sources on the HTTP/management ports, so Gateway, ServiceMonitor
  and the reconciler Jobs should still reach it — but this was read from the CRD text, not observed.
 - **The passkey reconciler's 26.0.6 Admin API assumptions against 26.8.2** (README "Upgrading
  Keycloak" list) — not re-checked here; PR #121 merged without it.
 - `catalog/keycloak.yaml`'s documentation-only image tag was not updated.
@@ -0,0 +1,60 @@
 ---
 date: 2026-11-08
 branch: fix/keycloak-servicemonitor-owner
 title: One owner for the keycloak ServiceMonitor — disable the 26.8 operator's (409 loop stalled platform-config)
 ---
 ## What changed
 - `platform/keycloak/keycloak-instance.yaml`: added `spec.serviceMonitor.enabled: false`.
  The 26.x Keycloak operator creates its own ServiceMonitor, named after the CR (`keycloak/keycloak`),
  whenever `metrics-enabled=true` and the ServiceMonitor CRD exists. `serviceMonitor.enabled` defaults
  to `true` in the 26.8.2 CRD, both in v2alpha1 and in v2beta1 (v2beta1 is now the storage version).
  That is the same name and namespace as the repo's Flux-owned `platform/keycloak/servicemonitor.yaml`.
  After the 26.0.6 -> 26.8.2 bump (#121/#144) the operator's PATCH against it returned
  `409 Conflict` and it ran out of retries. The CR then sat at `Ready=False`/`HasErrors=True`, and
  `platform-config` (`wait: true`, which health-checks every object it applies, this CR included)
  blocked everything that `dependsOn` it: velero, apps-vms, apps-wave-0 (and so waves 1/2 and
  pm-agent), homepage, oauth2-proxy, headlamp, conformance, vpn-ingress, crafty, runbooks.
 - `platform/keycloak/servicemonitor.yaml`: a comment saying it is the sole owner.
 - **Why ours is kept:** these are written against it: the L0 `servicemonitor-ports-resolve`
  allow-list entry `platform/keycloak/servicemonitor.yaml:keycloak`, the L2 `keycloak-monitored`
  chainsaw test, the README's ownership table, and the dashboard's `up{namespace="keycloak"}`.
  The operator's version (upstream `KeycloakServiceMonitorDependentResource` @26.8.2) scrapes the same
  target: port name `management` (9000 on `keycloak-service`), path `/metrics`, interval 30s,
  selector = the operator's instance labels. It offers nothing ours lacks, so having two owners
  would add a fight and gain nothing.
 ## What I verified
 - Live, read-only, `k3s-prod` ~06:25Z: the CRD schema field `spec.serviceMonitor.enabled`
  (`default: true`) exists in both served versions. The live `keycloak` ServiceMonitor has exactly
  **one** managedFields manager, `kustomize-controller` (Apply, 2026-09-05), **no ownerReferences**,
  and labels `kustomize.toolkit.fluxcd.io/name=platform-config`, `release=kube-prometheus-stack`. So
  the operator's apply never landed, and nothing on the object ties it to the Keycloak CR.
 - The ServiceMonitor will not be deleted when the operator is switched off: the operator's dependent
  informer is filtered on `Constants.DEFAULT_LABELS_AS_STRING`
  (`app.kubernetes.io/managed-by=keycloak-operator`). Our object does not carry that label and has
  no ownerReference, so the operator cannot see it as its secondary and cannot delete or GC it.
  This conclusion comes from reading the code. It was not observed.
 - The other operator dependents in ns `keycloak` do not collide with anything: `keycloak-service`,
  `keycloak-discovery`, the StatefulSet `keycloak`, `keycloak-initial-admin`, and
  `keycloak-network-policy` (owner Keycloak, no Flux label). The repo declares none of these names.
  It only *references* `keycloak-service` by name (HTTPRoute, reconcilers). There are no PDBs in the
  namespace, and the Ingress is already `enabled: false`. The only NetworkPolicy in the namespace is
  the operator's. The repo has no Keycloak NetworkPolicy, and no Kyverno-generated default-deny is
  present there. NetworkPolicies add up, so the operator's allow-policy cannot fight another owner.
  Left at its default.
 - Local gate: see the PR body. It records the rc and stages.
 ## What I did NOT verify
 - That the CR reaches `Ready=True`/`HasErrors=False` after merge. The status also says
  "Performing Keycloak upgrade, scaling down the deployment". I am inferring that this half clears
  once the workflow stops erroring. It is not proven.
 - That the operator stops issuing the PATCH once `enabled: false` is applied. Watch the operator
  logs for 409.
 - That `platform-config` and its downstream Kustomizations go Ready on the new revision, and that
  Prometheus keeps exactly one `serviceMonitor/keycloak/keycloak/0` pool with targets up.
 - The operator's actual label set for `DEFAULT_LABELS_AS_STRING`. I took it from the observed labels
  on operator-created objects, not from `Constants.java`.
@@ -0,0 +1,65 @@
 ---
 date: 2026-11-08
 branch: chore/renovate-config-cleanup
 title: Renovate config — hand-migrate the docker key, track gitea/runner, keep HelmRelease range lower bounds
 ---
 ## What changed
 - **`renovate.json5`: the deprecated top-level `"docker": {"enabled": true}` is hand-migrated** to
  `packageRules[0] = {"matchCategories": ["docker"], "enabled": true}`, the exact shape Renovate's
  own migration produced on `origin/renovate/migrate-config` (PR #139). Its comment moved with it.
  This replaces #139, which was closed because its rewrite deleted every comment in the file. No
  other comment was removed or reflowed (diff is additions plus the moved block).
 - **`gitea/runner` added to the blast-radius rule** beside `gitea/act_runner`, with a comment:
  act_runner was renamed upstream to gitea/runner after 0.6.1; Renovate does not follow renames,
  so the actual image migration is a separate manual PR.
 - **Two new packageRules for flux/helm `>=A <B` ranges:** `rangeStrategy: "bump"`, plus
  `matchUpdateTypes: ["bump"] -> enabled: false`, so in-range releases (which Flux adopts on its
  own) do not become PRs. Cause of the bug, from the 44.167.0 source: rangeStrategy is unset
  (`auto`); the flux manager has no `getRangeStrategy`/`updateLockedDependency`, so
  `lib/modules/manager/index.ts getRangeStrategy` resolves `auto` to `replace`; helm versioning is
  the npm api verbatim, and npm `getNewValue` under `replace` turns `>=1.12.0 <1.13.0` into
  `<1.14.0` (what PRs #131, #130 and #115 did).
 - **`platform/headlamp/helmrelease.yaml`: `version: "<0.47.0"` -> `">=0.46.0 <0.47.0"`**, comment
  refreshed. The live chart is 0.46.0, so the set of installable charts is unchanged.
 ## What I verified
 - **Semantic diff of #139:** I parsed `renovate.json5` on `origin/renovate/migrate-config` and on its
  parent `5b484f6` with json5 (the copy inside the renovate image). With `docker` removed from the
  parent and `packageRules[0]` removed from the migrated file, the two are identical. So the only
  change was `{"matchCategories":["docker"],"enabled":true}`, inserted at packageRules[0].
 - **Validator, `ghcr.io/renovatebot/renovate:44.167.0`** (the tag that `.gitea/workflows/renovate.yaml`
  pins as `container.image`): `renovate-config-validator` gives `Config validated successfully`
  (rc 0), and so does `--strict` (rc 0), both as a file path and in repo mode. **`--strict` on
  origin/main's file gives rc 1** and prints the `docker` migration diff. Nothing is left to migrate.
 - **`getNewValue` called in the 44.167.0 image** (helm versioning), currentValue
  `>=1.12.0 <1.13.0`, newVersion 1.13.0: replace `<1.14.0`, widen `>=1.12.0 <1.14.0`,
  bump `>=1.13.0 <1.14.0`, pin/update-lockfile `<1.14.0`. On `<0.47.0`, bump returns the value
  unchanged, so it would never propose anything for that range. That is why the rule is scoped to
  the `>=A <B` shape.
 - **Local dry run** (`--platform=local`, `RENOVATE_DRY_RUN=lookup`, 44.167.0, live chart repos)
  against a fixture repo of four HelmReleases under `platform/`:
  - With this branch's config: `No config migration necessary`. longhorn `>=1.9.0 <1.10.0` ->
    `>=1.13.0 <1.14.0` (minor). kube-prometheus-stack `>=88.0.0 <89.0.0` -> `>=93.1.0 <94.0.0`
    (major). The in-range bump `>=88.6.5 <89.0.0` was dropped (`Filtered out 1 disabled update(s)`).
    headlamp `>=0.46.0 <0.47.0` and `<0.47.0`: no update.
  - Control run with origin/main's config: `Config migration necessary`, longhorn -> `<1.14.0`,
    kube-prometheus-stack -> `<94.0.0`. This reproduces the reported bug.
 - Live headlamp HelmRelease (read-only kubectl, k3s-prod): spec `<0.47.0`, history chartVersion
  `0.46.0`, Ready `True`.
 ## What I did NOT verify
 - **I have not seen a real scheduled Renovate run against this repo with this config.** The claim that
  Renovate stops reopening the migrate-config PR rests on the validator and on `No config migration
  necessary` in the local dry run, not on the Gitea bot. After merge, watch the next run, and if
  `renovate/migrate-config` is still on the remote, delete it.
 - **Under bump, the new lower bound is the release Renovate proposes**, e.g. `>=1.13.2 <1.14.0`, not
  `>=1.13.0`. Flux still installs the newest release in the window. Ranges with other shapes keep the
  default `replace`: `3.9.x`, `~`, ceiling-only, and exact pins.
 - **The open PRs #131, #115 and any others still carry unbounded `<X` values.** They were generated
  under the old strategy, and Renovate should rebase or regenerate them under bump on its next run.
  I have not checked that it does.
 - The gitea/runner rename itself (a new image reference and any config changes) is not done here.
@@ -0,0 +1,48 @@
 ---
 date: 2026-11-08
 branch: rework/136
 title: "PR #136 rework: regenerate L1 render goldens for the oauth2-proxy v7.15.6 sidecar bump"
 ---
 ## What changed
 - Renovate PR #136 bumps `OAUTH2_PROXY_IMAGE` in `catalog/render.py` (and the generated
  `apps/wave-*` / `platform/crafty` pins) from `v7.8.1` to `v7.15.6`. Its gate failed at L1
  because three byte-for-byte render goldens still carried the old tag:
  - `conformance/tests/l1-rendering/container-workload-render/golden/expected.yaml`
  - `conformance/tests/l1-rendering/egress-class-render/golden/egress-vpn.expected.yaml`
  - `conformance/tests/l1-rendering/egress-class-render/golden/egress-internet.expected.yaml`
    (CI only reported the vpn one because `render-check.sh` stops at the first failing diff;
    the internet golden had drifted too.)
 - Regenerated all three in the pinned toolbox with the exact invocation the check scripts use:
  `python3 catalog/render.py <fixture> > <golden>`. The diff in each is **one line**:
  `image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1` -> `...:v7.15.6`. Nothing else moved.
 - `platform/crafty/README.md`: the "Sidecar" row described the current pin; updated to v7.15.6.
 - Deliberately NOT changed (they record history, not the current pin):
  - `catalog/render.py` comments / assertion messages saying a flag was "confirmed present in the
    PINNED v7.8.1 binary" or that `--api-routes` "does not exist in v7.8.1". Rewriting them to
    v7.15.6 would assert a `--help` verification nobody has done against v7.15.6.
  - `conformance/tests/l0-static/oauth2-proxy-api-routes-per-app/check.sh`, the schema
    description, `runbooks/oauth2-proxy-session.md`, `docs/plans/...` — same reasoning.
  - `platform/oauth2-proxy/auth-visibility-alerts.promtool-test.yaml` — v7.8.1 appears in
    synthetic kube-state-metrics series (test input data), not as a pin.
  - `.gitea/workflows/renovate.yaml` comment — a dated measurement of the pre-Renovate state.
 - Branch was 55 commits behind `origin/main`, but main touches neither `catalog/render.py` nor
  the L1 goldens, and the merge is conflict-free; no merge of main was needed for the gate.
 ## What I verified
 - The golden diff is exactly the image tag in each of the three files (`git diff -U0`).
 - No remaining `oauth2-proxy:v7.8.1` in any rendered/generated/golden file (`git grep`).
 - Local toolbox gate result: see the PR #136 comment posted with this push (rc and per-stage
  results are quoted there and in the worker report).
 ## What I did NOT verify
 - That the v7.15.6 sidecar actually starts and authenticates in the cluster with the rendered
  args. Earlier research said no flag used here was removed/renamed between 7.8.1 and 7.15.6;
  I did not re-run `oauth2-proxy --help` against the v7.15.6 image.
 - L2/L3 conformance (does not run in CI: `CLUSTER_AVAILABLE` unset).
 - `approval-policy`: `conformance/**` is a sensitive path, so this PR is CI-red until the
  operator posts `/approve-override <reason>` as a PR review. The local gate cannot evaluate it.
 - Whether Renovate keeps rebasing this branch now that it carries a non-Renovate commit.
@@ -0,0 +1,155 @@
 ---
 date: 2026-11-08
 branch: feat/runner-capacity-2
 title: act_runner runs two jobs at once, and dind is sized for two
 ---
 ## What changed
 `apps/wave-1/gitea-actions.yaml` only. That file is a **hand-owned** non-catalog unit
 (`EXTRA_UNITS["gitea-actions"]` in `catalog/render.py`): the renderer only decides which wave
 it lands in, it does not generate its bytes, and `ci/render-golden.sh` compares only files the
 catalog renders. So it is edited in place, and no re-render was needed or run.
 1. **New ConfigMap `act-runner-config`** holding a config file with ONE key,
   `runner.capacity: 2`, mounted read-only at `/etc/act_runner/` and selected with
   `CONFIG_FILE=/etc/act_runner/config.yaml`. The image's `run.sh` (act_runner v0.6.1) turns
   that into `--config` for both `register` and `daemon`.
   - Deltas only, on evidence: v0.6.1 `LoadDefault()` unmarshals the file onto a zero Config and
     then applies the same defaults as the no-file path, so the other settings are unchanged.
   - The `generate-config` example was deliberately NOT used. Its `runner.labels` would override
     the registered labels in `/data/.runner` and repoint `ubuntu-latest` at
     `docker.gitea.com/runner-images`. Its `force_pull: true` is not the default. Its sample `envs`
     would be injected into every job.
   - With a file present, act_runner ignores the legacy `GITEA_RUNNER_CAPACITY` /
     `_FILE` / `_ENVIRON` / `_ENV_FILE` / `GITEA_DEBUG` / `GITEA_TRACE` env vars. None of
     them is set on this Deployment.
 2. **Pod-template annotation `homelab.keithjackson.dev/act-runner-config-revision: "1"`.**
   act_runner reads its config once, at start, so a change to the ConfigMap alone would never
   take effect. Bump this annotation whenever you change only the ConfigMap.
 3. **dind resources:** requests `cpu 100m -> 2` and `memory 256Mi -> 1Gi`; limit
   `memory 2Gi -> 4Gi`. There is still no CPU limit, on purpose.
 4. **runner resources:** request `memory 128Mi -> 256Mi`, limit `memory 512Mi -> 1Gi`. CPU stays
   at `100m`.
 Why these sizes. Measured 2026-11-08 through Prometheus, at capacity 1:
 | container | peak CPU (1m rate, 30d) | peak working set (30d) | OOM events (7d) |
 |---|---|---|---|
 | dind | 0.69 core | 447 MiB | 0 |
 | runner | 0.24 core | 314 MiB | 0 |
 At the moment of measurement the pod was idle (`top`: dind 1m/138Mi, runner 1m/83Mi), on
 k3s-prod-2.
 - **CPU request 2.** Two jobs at today's peak is about 1.4 cores. The gate is being parallelised
  in other work, so each job will use more than that. The request sets dind's CFS weight under
  contention; at 100m it got a 1/20 share. With no limit, dind can still use spare cores on an
  idle node.
 - **Memory 1Gi / 4Gi.** Two jobs at today's peak is about 0.9 GiB. If dind is OOM-killed,
  dockerd goes down and takes both running jobs with it, so the limit is about 4x that.
 - **Runner limit 512Mi -> 1Gi.** Its 30-day peak was already 61% of the old limit, and with
  capacity 2 it holds state for two tasks.
 Scheduling headroom: CPU requests per node were measured with `describe node`. The pod's total
 CPU request goes from 200m to 2100m (+1.9 cores).
 | node | CPU requested now | after the change | allocatable |
 |---|---|---|---|
 | prod-2 (current) | 2945m | ~4845m (61%) | 8 |
 | prod-1 | 3175m | ~5075m | 8 |
 | prod-3 | 3840m | ~5740m (72%) | 8 |
 The pod fits on any of the three if the RWO PVC moves it.
 Concurrency semantics. Workflow `concurrency:` groups are enforced by Gitea on the server, not by
 the runner, so capacity does not change them:
 - `gate.yml` `gate-${{ github.ref }}` with cancel-in-progress still cancels a superseded run on
  the same ref.
 - `renovate` (group `renovate`, no cancel) and `images-${{ github.ref }}` still serialise
  themselves.
 What capacity 2 does change: runs on *different* refs (a PR gate next to a renovate or images
 run, or two PRs) now run side by side instead of queueing. The required check
 `gate / gate (pull_request)` is still one job per PR head, and gate.yml's other job
 (`conformance`) is `if: false`, so it never runs.
 Both jobs share one dockerd. act_runner gives each task its own container prefix
 (`GITEA-ACTIONS-TASK-<task id>`) and its own network, and no workflow uses fixed container names
 or host ports.
 ## What I verified
 - **Source of truth.** `catalog/render.py` `EXTRA_UNITS` places `gitea-actions.yaml` by
  anchor/offset only. `ci/render-golden.sh` iterates over rendered files only, so this file is
  outside render==golden. No `--emit-waves` was run.
 - **act_runner v0.6.1 behaviour, read in its source** (tag v0.6.1):
  - `config.LoadDefault()` treats a partial file as described above.
  - `daemon.go`: config labels override `.runner` labels only when non-empty.
  - `poller.go`: a semaphore of `cfg.Runner.Capacity` bounds concurrent tasks.
  - `runner.go`: per-task container name prefix.
  - The image's `run.sh`, read from `gitea/act_runner:0.6.1`, honours `CONFIG_FILE`.
 - **The live pod has no config file today.** `/data` holds only `.runner` and `lost+found`.
  `act_runner --version` reports v0.6.1. No LimitRange or ResourceQuota exists in
  `gitea-actions`.
 - **Resource numbers.** All figures above come from read-only `kubectl top`, `describe node` and
  Prometheus queries against k3s-prod.
 - **dind disk.** The emptyDir sits on the node's 11.8G ephemeral filesystem: 4.0G used, 7.2G
  free. Image cache is 2.18GB, which is the one `catthehacker/ubuntu:act-22.04` image. Two
  concurrent jobs share that image.
 - **Embedded config.** It parses as YAML to `{'runner': {'capacity': 2}}`. The only `$` in the
  manifest is the existing `${BASE_DOMAIN}`, so nothing new is exposed to Flux postBuild
  envsubst.
 - **Approval policy.** `apps/wave-1/` matches no `sensitive_paths` glob in
  `infra/gitea/approval-policy.json`, so this PR merges on a green gate alone.
 - **Local gate.** Pinned toolbox, run from the worktree on the committed tree. The rc and skipped
  stages are given in the PR description.
 ## What I did NOT verify
 - **UNVERIFIED: that the runner actually starts with the config and runs two jobs at once.**
  Nothing is applied until Flux reconciles `main`.
 - **Capacity cannot be seen through Gitea's API.** act_runner v0.6.1 does not report capacity to
  Gitea: `Declare` sends only version and labels. `GET /api/v1/admin/actions/runners` therefore
  cannot show "capacity 2". Concurrency has to be observed instead.
 - **UNVERIFIED: whether the parallelised gate fits in these sizes.** That gate has not landed.
  Re-measure after it does, with
  `max_over_time(sum by (container)(rate(container_cpu_usage_seconds_total{namespace="gitea-actions"}[1m]))[7d:30s])`.
 - **Rollout cancels in-flight jobs.** The rollout restarts the runner pod (strategy Recreate,
  `shutdown_timeout: 0s`), and any job running at that moment is cancelled, possibly including
  the `push`-to-main gate run triggered by this very merge. Re-run it if that happens.
 - **dind disk is not bounded by a limit.** With two jobs it holds two jobs' workspaces and layers
  on the same 11.8G node filesystem. I did not add an `ephemeral-storage` limit, because an
  eviction would kill both jobs. Watch kubelet DiskPressure on the runner's node.
 - **Stale comments in sensitive paths.** `.gitea/workflows/gate.yml` (line ~52) and
  `.gitea/workflows/README.md` (line ~86) still say "`act_runner` runs at capacity 1". I left
  them alone because `.gitea/**` is a sensitive path and editing them would put this PR behind
  human approval. Fix them in a separate PR.
 ### Operator post-merge checklist
 1. Flux applied it:
   `kubectl --context k3s-prod -n flux-system get kustomization apps-wave-1 -o jsonpath='{.status.lastAppliedRevision}'`
   equals the merge commit.
 2. The pod restarted with the config:
   - `kubectl --context k3s-prod -n gitea-actions get pod -l app.kubernetes.io/name=act-runner`
     shows a new pod, 2/2 Running.
   - `kubectl ... exec deploy/act-runner -c runner -- cat /etc/act_runner/config.yaml` shows
     `capacity: 2`.
   - `kubectl ... exec deploy/act-runner -c runner -- ps` shows `act_runner daemon --config /etc/act_runner/config.yaml`.
   - The logs show "declare successfully" with the two expected labels (`ubuntu-latest`,
     `homelab` -> `catthehacker/ubuntu:act-22.04`). That confirms the labels did not change.
 3. The runner is registered and online:
   - `GET /api/v1/admin/actions/runners` lists `incluster-dind`, online, with the same ID as
     before (no duplicate row).
   - Capacity is NOT shown there; see above.
 4. Concurrency is real: trigger two runs on different refs (e.g. two PR gates, or a PR gate plus a
   `workflow_dispatch` of renovate). Then either:
   - in `GET /api/v1/repos/Home-Network/home-network-k3s-impl/actions/tasks`, confirm their
     `run_started_at` .. `updated_at` windows overlap; or
   - check
     `docker --host=tcp://127.0.0.1:2376 --tlsverify ... ps` in the dind container lists two
     `GITEA-ACTIONS-TASK-*` container sets at once.
 5. Resources: `kubectl --context k3s-prod -n gitea-actions describe pod` shows dind requests
   cpu 2 / memory 1Gi, limit memory 4Gi, and runner limit memory 1Gi.
@@ -16,7 +16,7 @@ Cilium L2 LoadBalancer (game protocols authenticate players themselves).
 |---|---|
 | Image | `registry.gitlab.com/crafty-controller/crafty-4:4.10.8` (current stable; bare-semver tags, no `v`) |
 | Web UI | HTTPS **self-signed** on `:8443` (reached only via the sidecar / same-pod) |
-| Sidecar | `quay.io/oauth2-proxy/oauth2-proxy:v7.8.1`, reverse-proxy on `:4180` |
+| Sidecar | `quay.io/oauth2-proxy/oauth2-proxy:v7.15.6`, reverse-proxy on `:4180` |
 | Data | ONE Longhorn RWO PVC `crafty-data` (20Gi), mounted 5× by subPath |
 | PVC subPaths | `servers`→`/crafty/servers`, `backups`→`/crafty/backups`, `logs`→`/crafty/logs`, `import`→`/crafty/import`, `config`→`/crafty/app/config` |
 | Identity | `runAsUser:1000 runAsGroup:0 fsGroup:0 runAsNonRoot:true` (see below) |
@@ -130,7 +130,7 @@ spec:
        - name: oauth2-proxy
          # quay.io/oauth2-proxy/oauth2-proxy — same authenticator family as platform/oauth2-proxy, but
          # here in per-app REVERSE-PROXY mode (--upstream is the co-located Crafty UI, not static://202).
-          image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
+          image: quay.io/oauth2-proxy/oauth2-proxy:v7.15.6
          imagePullPolicy: IfNotPresent
          args:
            - --http-address=0.0.0.0:4180
@@ -40,7 +40,11 @@ spec:
      # values (-session-ttl + the -oidc-* args from the externalSecret; useCookie stays default-false
      # so `-oidc-use-cookie` is NOT emitted) is supported by the v0.41.0 backend. Renovate maintains
      # within 0.41.x; the appVersion continues to pin the Headlamp image.
-      version: "<0.47.0"
+      # 2026-11-08: NOW 0.46.x. PR #130 (Renovate, default rangeStrategy `replace`) rewrote
      # `>=0.41.0 <0.42.0` to the unbounded-below `<0.47.0`; the lower bound is restored here at the
      # chart that was live when it merged (0.46.0). renovate.json5 now bumps `>=A <B` ranges as a window,
      # so the next widen PR proposes `>=0.47.x <0.48.0` rather than `<0.48.0`.
      version: ">=0.46.0 <0.47.0"
      sourceRef:
        kind: HelmRepository
        name: headlamp
@@ -367,9 +367,17 @@ is involved — so step 2 failing with no log entry is the expected signature of
 The `Keycloak` CR has no `spec.image`, so the server image is whatever the operator's
 `RELATED_IMAGE_KEYCLOAK` names — the same tag as the operator (prod, 2026-10-30: operator
 `26.0.6`, `keycloak-0/1` on `quay.io/keycloak/keycloak:26.0.6`). Operator, CRDs and server are
-released in lockstep from `keycloak/keycloak-k8s-resources`, and the three URLs in
+released in lockstep from `keycloak/keycloak-k8s-resources`, and the release URLs in
 `kustomization.yaml` are the one knob. Renovate raises them as ONE PR (`keycloak-operator` group,
 labels `needs-review` + `blast-radius`), **never auto-merged**; majors wait for a dashboard tick.
 **Renovate bumps the URLs that exist; it cannot add a CRD a release introduced.** Before merging a
 bump, diff `kubernetes/` (and its `kustomization.yml`) at the new tag against the URL list. 26.0.6
 shipped 2 CRDs, 26.8.2 ships 4 (`keycloakoidcclients`, `keycloaksamlclients` added); PR #121 bumped
 only the existing URLs and the 26.8.2 operator CrashLooped on the missing `keycloaksamlclients`
 informer, stalling Flux `platform` and every tier below it (2026-11-08,
 `decisions/2026-11-08-keycloak-operator-crds.md`). The operator's memory is also patched in
 `kustomization.yaml` (upstream's 450Mi OOMKilled 26.0.6 here); keep the patch across bumps.
 `catalog/keycloak.yaml`'s image tag is documentation only (its render deploys nothing) and
 Renovate is disabled for it — update it by hand to match after an operator bump merges.
@@ -38,6 +38,20 @@ spec:
  ingress:
    enabled: false                         # exposed via Gateway API HTTPRoute (httproute.yaml), not the
                                           # operator's built-in Ingress
  # --- ONE OWNER for the `keycloak` ServiceMonitor: this repo (servicemonitor.yaml), not the operator.
  #     Since 26.x the operator creates its OWN ServiceMonitor, named after this CR (`keycloak`, i.e.
  #     the SAME name/namespace as ours), whenever metrics-enabled=true and the CRD exists —
  #     spec.serviceMonitor.enabled defaults TRUE. On 2026-11-08, right after the 26.0.6 -> 26.8.2
  #     bump, its server-side apply onto our Flux-owned object failed `409 Conflict`, the operator
  #     exhausted retries, the CR sat Ready=False/HasErrors=True, and `platform-config` (wait: true,
  #     so it health-checks this CR) stalled every Kustomization downstream of it. Ours is kept
  #     because the L0 servicemonitor-ports-resolve and L2 keycloak-monitored conformance tests and
  #     the dashboard's up{namespace="keycloak"} are written against it; the operator's would scrape
  #     the same thing (management port 9000, /metrics, 30s). Do NOT flip this to true without
  #     deleting servicemonitor.yaml in the same change — two owners of one object is a fight
  #     (cf. the default-deny NetworkPolicy drift loop).
  serviceMonitor:
    enabled: false
  # --- Hardening + observability options (docs/15). Brute-force detection is a REALM setting
  #     (bruteForceProtected in the realm import); these enable health + metrics endpoints. ---
  additionalOptions:
@@ -20,19 +20,33 @@ kind: Kustomization
 namespace: keycloak
 resources:
  - namespace.yaml
-  # --- Keycloak Operator v26.0.6 (pinned upstream release manifests) ---
+  # --- Keycloak Operator v26.8.2 (pinned upstream release manifests) ---
  # The operator, its CRDs and the SERVER IMAGE move in lockstep: the Keycloak CR has no
  # spec.image, so the operator's RELATED_IMAGE_KEYCLOAK (quay.io/keycloak/keycloak:<same tag>)
-  # is what runs. These three URLs are therefore THE Keycloak version. Each carries a Renovate
+  # is what runs. These URLs are therefore THE Keycloak version. Each carries a Renovate
-  # marker (custom.regex manager, renovate.json5) under ONE depName, so all three bump in ONE
+  # marker (custom.regex manager, renovate.json5) under ONE depName, so all of them bump in ONE
  # branch, never auto-merged (packageRule "keycloak-operator"). Before merging a bump, re-check
  # passkey-reconciler.yaml's 26.0.6 Admin API assumptions — see README.md "Upgrading Keycloak".
  #
  # THE URL LIST MUST MATCH UPSTREAM'S kubernetes/kustomization.yml AT THE NEW TAG — Renovate only
  # rewrites the version in the URLs that are here; it cannot add a CRD the new release introduced.
  # 26.0.6 shipped 2 CRDs; 26.8.2 ships 4 (+ keycloakoidcclients, keycloaksamlclients, both
  # v2alpha1). PR #121 bumped only the existing three URLs, and the 26.8.2 operator — which starts an
  # informer for EVERY kind it controls, used or not — CrashLooped on
  # `Couldn't start informer for keycloaksamlclients.k8s.keycloak.org/v2alpha1 ... Not Found`,
  # stalling Flux `platform` and everything downstream (2026-11-08). On every bump, diff
  #   https://github.com/keycloak/keycloak-k8s-resources/tree/<tag>/kubernetes
  # against this list before merging.
  # renovate: datasource=github-tags depName=keycloak/keycloak-k8s-resources
-  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.0.6/kubernetes/keycloaks.k8s.keycloak.org-v1.yml
+  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.8.2/kubernetes/keycloaks.k8s.keycloak.org-v1.yml
  # renovate: datasource=github-tags depName=keycloak/keycloak-k8s-resources
-  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.0.6/kubernetes/keycloakrealmimports.k8s.keycloak.org-v1.yml
+  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.8.2/kubernetes/keycloakrealmimports.k8s.keycloak.org-v1.yml
  # renovate: datasource=github-tags depName=keycloak/keycloak-k8s-resources
-  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.0.6/kubernetes/kubernetes.yml
+  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.8.2/kubernetes/keycloakoidcclients.k8s.keycloak.org-v1.yml
  # renovate: datasource=github-tags depName=keycloak/keycloak-k8s-resources
  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.8.2/kubernetes/keycloaksamlclients.k8s.keycloak.org-v1.yml
  # renovate: datasource=github-tags depName=keycloak/keycloak-k8s-resources
  - https://raw.githubusercontent.com/keycloak/keycloak-k8s-resources/26.8.2/kubernetes/kubernetes.yml
  # --- Admin (break-glass) credential — SOPS-encrypted, referenced by name (ADR-0007, R-IDP-04) ---
  - keycloak-admin-credentials.sops.yaml
  # --- OIDC client secrets (grafana + oauth2-proxy) the realm import injects via placeholders ---
@@ -51,3 +65,23 @@ resources:
  - keycloak-db-backup-credentials-prod.sops.yaml
  # --- Grafana dashboard for Keycloak health (plain ConfigMap; R-OBS-03) ---
  - grafana-dashboard.yaml
 # --- Operator memory: upstream ships requests=limits=450Mi, which this cluster outgrew ON 26.0.6 ---
 # Measured on prod 2026-11-08: the 26.0.6 operator pod had 154 restarts in 64d, lastState
 # `OOMKilled` (exit 137, 2026-11-07T23:09:54Z), and sat at 421Mi of its 450Mi (94%) in `kubectl top`.
 # 26.8.2 keeps the same 450Mi default but runs FOUR controllers/informers instead of two (adds
 # keycloakoidcclient + keycloaksamlclient) on a newer Quarkus (3.15.1 -> 3.40.1.1), so it would
 # plausibly start above a ceiling 26.0.6 already crossed. Limit 768Mi = ~1.8x the observed 421Mi
 # working set; request 512Mi = the observed working set plus headroom, so the scheduler reserves what
 # it actually uses. Revisit with `kubectl top` once 26.8.2 has run for a week. Patched here (not in
 # the remote kubernetes.yml) so a Renovate bump keeps it.
 patches:
  - target:
      kind: Deployment
      name: keycloak-operator
    patch: |-
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: 768Mi
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/memory
        value: 512Mi
@@ -8,6 +8,9 @@
 # /metrics) once metrics-enabled/health-enabled are set (see keycloak-instance.yaml additionalOptions).
 # We select the operator-created keycloak-service (which selects the Keycloak pods) and scrape the pods'
 # management port by number via targetPort.
 # SOLE OWNER: the operator's own ServiceMonitor (same name `keycloak`) is switched OFF in
 #   keycloak-instance.yaml (spec.serviceMonitor.enabled: false) — 26.x defaults it ON and its apply
 #   409-looped against this object on 2026-11-08. Keep exactly one of the two.
 # TODO(WS-SEC, bring-up): confirm the management port number/name the operator exposes (9000 default)
 #   and adjust targetPort if the pinned operator changes it. The KeycloakDown / KeycloakDatabaseDown
 #   alerts (platform/monitoring/alerts.yaml) key on kube-state-metrics and fire regardless of this SM.
@@ -37,6 +37,8 @@
 //     renovate-config-validator /tmp/renovate.json5
 // (Not `--strict`: that also fails on a pending migration of the pre-existing top-level
 // `"docker": {"enabled": true}` block at the bottom, which is a warning, not an error.)
 // RESOLVED 2026-11-08: that block is now hand-migrated to the first packageRule (`matchCategories:
 // ["docker"]`), the exact shape Renovate's own migration produced, so no migration is pending.
 //
 // `regex` vs `custom.regex` in enabledManagers, RESOLVED FROM SOURCE (Renovate 39.264.0 and
 // later): both work. lib/config/migrations/custom/enabled-managers-migration.ts rewrites
@@ -142,7 +144,9 @@
      "description": "This repo's own CI-published images, pinned by digest, following the tag named in a `# renovate-digest:` marker on the previous line.",
      "managerFilePatterns": [
        "/(^|/)versions\\.env$/",
-        "/(^|/)platform/pm-agent/.+\\.ya?ml$/"
+        "/(^|/)platform/pm-agent/.+\\.ya?ml$/",
        // ADDED 2026-11-08: the merge gate's job `container:` is the toolbox, by digest.
        "/^\\.gitea/workflows/gate\\.ya?ml$/"
      ],
      "matchStrings": [
        "#\\s*renovate-digest:\\s*image=(?<depName>\\S+)\\s+tag=(?<currentValue>\\S+)\\s*\\n[^\\n]*?(?<currentDigest>sha256:[a-f0-9]{64})"
@@ -196,6 +200,22 @@
    }
  ],
  "packageRules": [
    // The `docker` manager (Dockerfiles, docker-compose) and the `kubernetes` manager above were
    // BOTH previously `enabled: false`, solely so Renovate would not fight Flux image-automation
    // over a running tag. That controller was never enabled and never will be here (see _comment),
    // so the only thing those two flags were achieving was leaving every plain `image:` tag in the
    // repo unmanaged. `docker` is left out of enabledManagers because this repo contains no
    // Dockerfile that ships to the cluster; `kubernetes` is now ON and is the one that matters.
    // MOVED HERE 2026-11-08 from a top-level `"docker": {"enabled": true}` key, which Renovate
    // deprecated (the top-level language objects became `matchCategories` rules). Hand-migrated to
    // the exact output of Renovate's own config migration (branch renovate/migrate-config, PR #139:
    // a json5 semantic diff of that file against its parent shows THIS rule, inserted at
    // packageRules[0], as the ONLY change). #139 itself was closed unmerged because its rewrite
    // dropped every comment in this file. With nothing left to migrate, Renovate stops reopening it.
    {
      "matchCategories": ["docker"],
      "enabled": true
    },
    {
      "description": "Auto-merge the allowed low-risk classes on green CI \u2014 no human authoring (R-UPD-02). The Gitea merge gate (make -C ci gate) is the required check.",
      "matchUpdateTypes": [
@@ -252,6 +272,11 @@
        // Keycloak's (the IdP) included, now that imageName is tracked.
        "gitea/gitea",
        "gitea/act_runner",
        // ADDED 2026-11-08. act_runner was RENAMED upstream to gitea/runner after 0.6.1
        // (https://gitea.com/gitea/runner/releases). Renovate does not follow a rename — it will
        // never propose gitea/act_runner -> gitea/runner — so that migration is a manual PR. Listed
        // now so the new name is blast-radius from its first reference, not after an auto-merge.
        "gitea/runner",
        "ghcr.io/cloudnative-pg/postgresql"
      ],
      "automerge": false,
@@ -264,7 +289,7 @@
    // and the server image are released in lockstep from keycloak/keycloak-k8s-resources, and the
    // Keycloak CR carries no spec.image, so the operator's RELATED_IMAGE_KEYCLOAK picks the server
    // (measured on prod 2026-10-30: operator 26.0.6 -> keycloak-0/1 run quay.io/keycloak/keycloak:
-    // 26.0.6). The three release URLs in platform/keycloak/kustomization.yaml carry `# renovate:`
+    // 26.0.6). The release URLs in platform/keycloak/kustomization.yaml carry `# renovate:`
    // markers under this ONE depName, so they move together in one branch (groupName makes that
    // explicit). NEVER AUTO-MERGED, not even a patch: Keycloak is the IdP that gates SSO for every
    // app AND kubectl OIDC, and platform/keycloak/passkey-reconciler.yaml encodes Keycloak 26.0.6
@@ -290,8 +315,8 @@
      "enabled": false
    },
    {
-      "description": "ADDED 2026-10-29. This repo's own images are followed ONLY through the `# renovate-digest:` markers above. The `kubernetes` manager also sees platform/pm-agent/deployment.yaml and infra/agent/worker-job-template.yaml, where the image has a digest and no tag; left on, it would look those up as `latest` (a tag CI never pushes) and, for the template, re-open the self-referential loop the custom manager deliberately avoids.",
+      "description": "ADDED 2026-10-29. This repo's own images are followed ONLY through the `# renovate-digest:` markers above. The `kubernetes` manager also sees platform/pm-agent/deployment.yaml and infra/agent/worker-job-template.yaml, where the image has a digest and no tag; left on, it would look those up as `latest` (a tag CI never pushes) and, for the template, re-open the self-referential loop the custom manager deliberately avoids. `github-actions` ADDED 2026-11-08 for the same reason: it extracts the gate job's digest-only `container: image:` in .gitea/workflows/gate.yml, which the custom manager already follows through its marker.",
-      "matchManagers": ["kubernetes"],
+      "matchManagers": ["kubernetes", "github-actions"],
      "matchPackageNames": [
        "gitea.home.keithjackson.dev/home-network/toolbox",
        "gitea.home.keithjackson.dev/home-network/agent-runner",
@@ -316,9 +341,9 @@
      "enabled": false
    },
    {
-      "description": "ADDED 2026-10-30. MIRRORS catalog/<svc>.yaml `update.range` — the operator's declared per-service policy (schemas/servicedefinition.schema.json), which Renovate does not read. Without it the dry run proposed gitea 28.2.0, qbittorrent 20.04.1 (both stale/odd tags, not real successors), radarr 6.x and nextcloud 35 (four majors past 31; Nextcloud cannot skip majors). KEEP IN STEP with the catalog ranges.",
+      "description": "ADDED 2026-10-30. MIRRORS catalog/<svc>.yaml `update.range` — the operator's declared per-service policy (schemas/servicedefinition.schema.json), which Renovate does not read. Without it the dry run proposed gitea 28.2.0, qbittorrent 20.04.1 (the qbittorrent tag is a stale/odd one, not a real successor; gitea 28.x IS the real successor of 1.27 — upstream dropped the \"1.\" prefix at 28.0.0 — and the catalog moved to it on 2026-11-07, so the gitea ceiling is now <29.0.0: 28.x patches/minors are proposed, never auto-merged per the blast-radius rule, and 29 waits for a human), radarr 6.x and nextcloud 35 (four majors past 31; Nextcloud cannot skip majors). KEEP IN STEP with the catalog ranges.",
      "matchPackageNames": ["gitea/gitea"],
-      "allowedVersions": "<2.0.0"
+      "allowedVersions": "<29.0.0"
    },
    { "matchPackageNames": ["nextcloud"], "allowedVersions": "<32.0.0" },
    { "matchPackageNames": ["lscr.io/linuxserver/qbittorrent"], "allowedVersions": "<6.0.0" },
@@ -368,6 +393,45 @@
      "automerge": false,
      "addLabels": ["needs-review", "range-widen"]
    },
    // ADDED 2026-11-08 — KEEP THE LOWER BOUND WHEN A MINOR-LOCKED RANGE MOVES. MEASURED PROBLEM:
    // PRs #131 (longhorn), #130 (headlamp) and #115 (kube-prometheus-stack) turned
    // `">=1.12.0 <1.13.0"` into `"<1.14.0"` — an UNBOUNDED-below range that also admits every
    // older chart (and #130 merged: platform/headlamp/helmrelease.yaml carried `<0.47.0`). WHY,
    // from the 44.167.0 source this file is validated against: no rangeStrategy is set, so it is
    // `auto`; the flux manager has no getRangeStrategy and no updateLockedDependency, so
    // lib/modules/manager/index.ts getRangeStrategy resolves `auto` -> `replace`. The helm
    // datasource's defaultVersioning is `helm`, which is the npm versioning api verbatim
    // (lib/modules/versioning/helm/index.ts: `api = { ...npm }`), and npm getNewValue under
    // `replace` rewrites `>=A <B` to just `<C`. Calling that getNewValue in the 44.167.0 image for
    // currentValue `>=1.12.0 <1.13.0`, newVersion 1.13.0:
    //   replace -> `<1.14.0`   widen -> `>=1.12.0 <1.14.0`   bump -> `>=1.13.0 <1.14.0`
    // Only `bump` keeps a one-minor window. (widen keeps the bound but grows the window by a minor
    // on every PR — the opposite of minor-locking.) Under bump the new lower bound is the release
    // proposed (e.g. 1.13.2 -> `>=1.13.2 <1.14.0`); Flux still picks the newest that satisfies it.
    // Scoped to the bounded `>=A <B` shape only: on a ceiling-only range like `<0.47.0` bump
    // returns the value unchanged, so Renovate would silently propose NOTHING for it, ever.
    {
      "description": "ADDED 2026-11-08. HelmRelease `version: \">=A <B\"` ranges move as a whole window (rangeStrategy bump), so a range-widen PR yields `>=1.13.0 <1.14.0`, not `<1.14.0`. See the comment above for the measured cause.",
      "matchManagers": ["flux"],
      "matchDatasources": ["helm"],
      "matchCurrentValue": "/^>=\\S+ <\\S+$/",
      "rangeStrategy": "bump"
    },
    // ...AND DO NOT LET bump ADD NOISE. Under bump Renovate also raises the lower bound for a
    // release ALREADY INSIDE the range (lib/workers/repository/process/lookup/generate.ts sets
    // isBump; e.g. 1.12.5 against `>=1.12.0 <1.13.0` -> `>=1.12.5 <1.13.0`), which `replace` never
    // proposed. Flux already installs that release with no PR, and the range-widen rule above
    // would hold every one for review. util/package-rules/update-types.ts matches isBump as
    // updateType `bump`, so exactly those updates are switched off here; out-of-range moves are
    // ordinary minor/major updates and are unaffected.
    {
      "description": "ADDED 2026-11-08. No PR for a chart release the HelmRelease range already admits — Flux adopts it on its own.",
      "matchManagers": ["flux"],
      "matchDatasources": ["helm"],
      "matchCurrentValue": "/^>=\\S+ <\\S+$/",
      "matchUpdateTypes": ["bump"],
      "enabled": false
    },
    {
      "description": "ADDED 2026-10-30. velero-plugin-for-aws is pinned to a RELEASE CANDIDATE (v1.14.3-rc.2) and Renovate proposed NOTHING for it, although v1.14.3 and v1.14.4 are stable on Docker Hub. Docker versioning treats everything after the first `-` as a compatibility SUFFIX, so only other `*-rc.2` tags qualify and the RC is a fossil forever. Semver versioning reads it as a prerelease, and a prerelease upgrades to the stable release.",
      "matchPackageNames": ["velero/velero-plugin-for-aws"],
@@ -439,14 +503,5 @@
    "conformance/tests/**",
    "platform/image-automation/per-service/**",
    "platform/kyverno/tests/**"
-  ],
+  ]
  // The `docker` manager (Dockerfiles, docker-compose) and the `kubernetes` manager above were
  // BOTH previously `enabled: false`, solely so Renovate would not fight Flux image-automation
  // over a running tag. That controller was never enabled and never will be here (see _comment),
  // so the only thing those two flags were achieving was leaving every plain `image:` tag in the
  // repo unmanaged. `docker` is left out of enabledManagers because this repo contains no
  // Dockerfile that ships to the cluster; `kubernetes` is now ON and is the one that matters.
  "docker": {
    "enabled": true
  }
 }
Author	SHA1	Message	Date
jakman85	6e2e353bcc	Merge pull request 'feat(ci): run the merge gate inside the CI-built toolbox image, pinned by digest' (#147 ) from feat/gate-toolbox-container into main gate / gate (push) Successful in 2m33s Details gate / conformance (push) Skipped Details Reviewed-on: #147 Reviewed-by: Keith Jackson <[email protected]>	2026-11-08 06:51:00 +00:00
jakman85	045d81c7a2	Merge pull request 'feat(gitea-actions): act_runner capacity 2, dind sized for two concurrent jobs' (#146 ) from feat/runner-capacity-2 into main gate / gate (push) Canceled after 1m15s Details gate / conformance (push) Canceled after 0s Details Reviewed-on: #146	2026-11-08 06:47:05 +00:00
jakman85	7be693bf37	Merge pull request 'chore(deps): Update quay.io/oauth2-proxy/oauth2-proxy Docker tag to v7.15.6' (#136 ) from renovate/quay.io-oauth2-proxy-oauth2-proxy-7.x into main gate / gate (push) Canceled after 1m32s Details gate / conformance (push) Canceled after 0s Details Reviewed-on: #136 Reviewed-by: Keith Jackson <[email protected]>	2026-11-08 06:45:31 +00:00
jakman85	9e9a3ea8cc	Merge pull request 'fix(keycloak): one owner for the keycloak ServiceMonitor (26.8 operator 409 loop blocks Flux)' (#148 ) from fix/keycloak-servicemonitor-owner into main gate / gate (push) Successful in 3m0s Details gate / conformance (push) Skipped Details Reviewed-on: #148	2026-11-08 06:37:13 +00:00
jakman85andClaude Opus 5.5	64c5617ddd	docs(decisions): record CI runs 500/503 for gate-toolbox-container gate / gate (pull_request) Successful in 2m20s Details gate / conformance (pull_request) Skipped Details Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:26:27 -06:00
jakman85andClaude Opus 5.5	35ba875380	fix(keycloak): one owner for the keycloak ServiceMonitor (26.8 operator 409 loop blocks Flux) gate / gate (pull_request) Successful in 3m2s Details gate / conformance (pull_request) Skipped Details The 26.x Keycloak operator creates its own ServiceMonitor named after the CR (keycloak/keycloak) when metrics are enabled; spec.serviceMonitor.enabled defaults true. That collides with the Flux-owned platform/keycloak/ servicemonitor.yaml: the operator's PATCH 409s, it exhausts retries, the CR stays Ready=False/HasErrors=True, and platform-config (wait: true) stalls every downstream Kustomization. Keep the repo's ServiceMonitor (conformance L0/L2 and the dashboard are written against it; the operator's scrapes the same port 9000 /metrics) and set spec.serviceMonitor.enabled: false. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:25:45 -06:00
jakman85andClaude Opus 5.5	27d603f726	fix(ci): umask 0022 in the git checkout step — act's 0000 made Ansible ignore ansible.cfg gate / gate (pull_request) Failing after 2m20s Details gate / conformance (pull_request) Skipped Details Run 500 (this PR's first CI run) failed L0 prod-baremetal-not-dev-surface: act runs steps with umask 0000, the checkout was world-writable, and Ansible (now present, via the toolbox) refuses a world-writable directory as an ansible.cfg source. Reproduced and fixed locally in the pinned image. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:20:38 -06:00
jakman85	1a33814522	Merge pull request 'chore(renovate): hand-migrate docker key, track gitea/runner, keep range lower bounds' (#145 ) from chore/renovate-config-cleanup into main gate / gate (push) Successful in 2m59s Details gate / conformance (push) Skipped Details Reviewed-on: #145	2026-11-08 06:17:59 +00:00
jakman85	4a3f6dee59	Merge pull request 'fix(keycloak): install the 26.8.2 operator's new CRDs (operator CrashLoop)' (#144 ) from fix/keycloak-operator-crds into main gate / gate (push) Canceled after 0s Details gate / conformance (push) Canceled after 0s Details Reviewed-on: #144	2026-11-08 06:16:56 +00:00
jakman85andClaude Opus 5.5	514ed5d5a4	docs(decisions): record local gate result for gate-toolbox-container gate / gate (pull_request) Failing after 2m31s Details gate / conformance (pull_request) Skipped Details Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:15:38 -06:00
jakman85andClaude Opus 5.5	9537ca2ddb	feat(ci): run the merge gate inside the CI-built toolbox image, pinned by digest The gate job now runs in gitea.home.keithjackson.dev/home-network/toolbox@sha256:83a3501e... (the image images.yaml publishes from infra/devcontainer/Containerfile) instead of catthehacker/ubuntu:act-22.04 plus a per-run download of yamllint, check-jsonschema, kyverno, promtool and chainsaw. Local (dev.sh) and CI now gate on the identical toolchain. - actions/checkout (Node) replaced by a plain-git step with fetch-depth-0 semantics; the toolbox has no Node. The job token is not persisted into .git/config. - The install step is replaced by a check that every ci/versions.env pin equals the image's /etc/dev-toolchain-versions, so the pins stay enforced. - Renovate follows the digest through a `# renovate-digest:` marker; github-actions manager disabled for own images. - install-tools.sh kept (merge-gate.yaml blueprint + alert-rules-unit-tested check use it). Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:12:03 -06:00
jakman85andClaude Opus 5.5	b548224db8	feat(gitea-actions): act_runner capacity 2, dind sized for two concurrent jobs gate / gate (pull_request) Successful in 2m59s Details gate / conformance (pull_request) Skipped Details The in-cluster runner ran at the default capacity 1 with no config file, so gate / images / renovate runs on different refs queued behind each other (29-759s waits; run 472 waited 759s behind a renovate burst). - ConfigMap act-runner-config with ONLY runner.capacity: 2, selected via CONFIG_FILE (honoured by the v0.6.1 image's run.sh). v0.6.1 LoadDefault() applies the same defaults to a partial file as to no file; the generate-config example is deliberately not used (its labels would override the registered ones, force_pull differs from the default). - Pod-template config-revision annotation so ConfigMap-only edits can roll it. - dind: cpu request 100m -> 2 (no limit), memory 256Mi/2Gi -> 1Gi/4Gi. Measured at capacity 1: peak 0.69 core, 447Mi working set (30d), 0 OOMs. - runner: memory 128Mi/512Mi -> 256Mi/1Gi (peak 314Mi at capacity 1). apps/wave-1/gitea-actions.yaml is a hand-owned EXTRA_UNITS file (the renderer only places it in a wave), so it is the source, not generated output. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:09:08 -06:00
jakman85andClaude Opus 5.5	759a0e51c8	chore(renovate): hand-migrate docker key, track gitea/runner, keep range lower bounds gate / gate (pull_request) Successful in 2m58s Details gate / conformance (pull_request) Skipped Details - Replace the deprecated top-level `docker` key with the packageRule Renovate's own migration produced (matchCategories docker, enabled true), keeping every comment. Supersedes #139, which dropped all comment lines. - Add gitea/runner (act_runner's upstream rename) to the blast-radius rule. - rangeStrategy bump for flux/helm `>=A <B` ranges: the default `auto` resolves to `replace`, which turned `>=1.12.0 <1.13.0` into `<1.14.0` (#131, #130, #115). In-range `bump` updates are disabled; Flux adopts those unaided. - Restore headlamp's lower bound: `<0.47.0` -> `>=0.46.0 <0.47.0` (live 0.46.0). Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:05:49 -06:00
jakman85andClaude Opus 5.5	ea30ba876c	fix(keycloak): install the 26.8.2 operator's new CRDs (operator CrashLoop) gate / gate (pull_request) Successful in 3m5s Details gate / conformance (pull_request) Skipped Details PR #121 bumped the three keycloak-k8s-resources URLs to 26.8.2, but 26.8.2 ships two more CRDs (keycloakoidcclients, keycloaksamlclients). The new operator fails to start its keycloaksamlclients informer (Not Found) and CrashLoops, holding Flux `platform` in health checks. - add both CRD URLs with the same renovate marker/depName - patch operator memory 450Mi -> limit 768Mi / request 512Mi (26.0.6 was OOMKilled at 421/450Mi, 154 restarts) - README/renovate comments: Renovate cannot add CRDs a release introduces Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-08 00:00:01 -06:00
jakman85andClaude Opus 5.5	3d7ecbcfe9	fix(conformance): regenerate L1 render goldens for oauth2-proxy v7.15.6 gate / gate (pull_request) Successful in 3m0s Details gate / conformance (pull_request) Skipped Details PR #136 bumps the renderer's OAUTH2_PROXY_IMAGE; the container-workload and egress-class (vpn + internet) goldens still pinned v7.8.1. Regenerated with the check scripts' own invocation; each diff is the image tag only. Also updates the crafty README's current-pin row. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-07 23:58:29 -06:00
jakman85	e8d26669a4	Merge pull request 'chore(deps): Update dependency keycloak/keycloak-k8s-resources to v26.8.2' (#121 ) from renovate/keycloak-operator into main gate / gate (push) Successful in 3m0s Details gate / conformance (push) Skipped Details Reviewed-on: #121	2026-11-08 05:53:29 +00:00
jakman85	048254bfaf	Merge pull request 'feat(gitea): upgrade 1.27.3 -> 28.3.0' (#142 ) from feat/gitea-28 into main gate / gate (push) Successful in 2m59s Details gate / conformance (push) Skipped Details Reviewed-on: #142	2026-11-08 05:41:34 +00:00
jakman85	dd94101647	Merge pull request 'feat(devcontainer): bake velero CLI into the toolbox, pinned to prod server v1.18.2' (#143 ) from feat/devcontainer-velero-cli into main gate / gate (push) Successful in 3m0s Details gate / conformance (push) Skipped Details images / images (push) Successful in 38s Details Reviewed-on: #143	2026-11-08 05:30:28 +00:00
jakman85andClaude Opus 5.5	8a9baa92bc	feat(gitea): upgrade 1.27.3 -> 28.3.0 gate / gate (pull_request) Successful in 3m13s Details gate / conformance (pull_request) Skipped Details Gitea dropped the "1." prefix; 28.x is the successor of 1.27. - image 28.3.0, update.range >=28.0.0 <29.0.0, Renovate ceiling <29.0.0 - drop GITEA__server__DOMAIN (no longer read in 28, ROOT_URL is the source) - declare RUN_RETENTION_DAYS=400, EGRESS_MODE=lax (no allow list: the OIDC login source is not gated by the egress policy in 28.3.0), and DISABLE_REGISTRATION=true (28's new default) - document autoRollbackOnFailedHealth as inert (no ImagePolicy is rendered); rollback is a PVC restore because the DB migration is one-way Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-11-07 22:55:06 -06:00
renovate-bot	893c9dee4f	chore(deps): Update quay.io/oauth2-proxy/oauth2-proxy Docker tag to v7.15.6 gate / gate (pull_request) Failing after 2m57s Details gate / conformance (pull_request) Has been skipped Details	2026-11-07 08:18:51 +00:00
renovate-bot	0605ecf593	chore(deps): Update dependency keycloak/keycloak-k8s-resources to v26.8.2 gate / gate (pull_request) Successful in 2m57s Details gate / conformance (pull_request) Has been skipped Details	2026-11-07 08:17:02 +00:00