home-network-k3s-impl/.gitea/workflows/renovate.yaml

# Renovate — the dependency/image update automation. SCHEDULED, self-hosted against this Gitea.
#
# ═══════════════════════════════════════════════════════════════════════════════════════════════
# WHY THIS FILE EXISTS: renovate.json HAS BEEN IN THIS REPO AND HAS NEVER ONCE RUN.
# ═══════════════════════════════════════════════════════════════════════════════════════════════
# Measured 2026-10-17: `renovate.json` is present, complete and thoughtfully written — it declares
# managers, schedules, automerge classes and grouping. Nothing executes it. There is no Renovate
# workflow (this is the first), no Renovate CronJob or Deployment in the cluster
# (`kubectl get cronjob,deploy,job -A | grep -i renovate` -> nothing), and no bot account doing it
# from outside. Meanwhile SEVEN files carry comments asserting "Renovate maintains this pin"
# (platform/homepage/deployment.yaml:40, runbooks/serving/deployment.yaml:87,
# platform/crafty/deployment.yaml:63, platform/vpn-ingress/daemonset.yaml:259,
# platform/keycloak/postgres-cluster.yaml:75, apps/wave-0/nextcloud-db.yaml:302, and
# platform/headlamp/helmrepository.yaml:2). Those comments have been false for the life of the file.
#
# The cost is measurable. With nothing bumping anything: the six per-app oauth2-proxy auth sidecars
# sit on v7.8.1 while the platform oauth2-proxy in the SAME cluster runs v7.15.5; Keycloak (the IdP)
# runs 26.0.6, a November-2024 release, 8 minors behind; Velero runs a RELEASE CANDIDATE
# (velero-plugin-for-aws v1.14.3-rc.2) with a stable available; the CNPG Postgres image is 16.4,
# missing every 16.5+ security release. A pin nothing maintains is not a pin, it is a fossil.
#
# ═══════════════════════════════════════════════════════════════════════════════════════════════
# WHY RENOVATE AND NOT FLUX IMAGE-AUTOMATION (the decision, and it reverses ADR-0009's split)
# ═══════════════════════════════════════════════════════════════════════════════════════════════
# ADR-0009 divided the work: Renovate owns Helm chart/dependency bumps, Flux image-automation owns
# per-service container image TAGS, deliberately non-overlapping. The second half of that split
# cannot be delivered on this repo's terms, for three measured reasons:
#
#   1. IT WOULD BYPASS THE MERGE GATE, WHICH CLAUDE.md §1 FORBIDS. ImageUpdateAutomation does not
#      open pull requests; it COMMITS AND PUSHES. Its default target is the source's own branch —
#      `main` — so it would write straight past the PR flow. It can be pointed at a side branch
#      instead, but then nothing opens the PR and bumps silently accumulate on a branch nobody
#      merges. Either way a human or a second bot has to close the loop.
#   2. ON THIS CLUSTER IT CANNOT EVEN DO THAT. Measured 2026-10-17: `main` is protected with
#      `user_can_push: false`, and the `flux-system` GitRepository has NO `spec.secretRef` at all —
#      the source is anonymous and read-only. Enabling write-back means minting an in-cluster git
#      WRITE credential for the repository that defines the cluster, which is a materially larger
#      blast radius than a CI-scoped token.
#   3. RENOVATE ALREADY OPENS PRs NATIVELY, so every change it proposes goes through the gate with
#      no extra machinery.
#
# So: Renovate owns BOTH halves, and Flux image-automation stays disabled. Note this is a change of
# plan, not a change of state — image-automation has been commented out at
# platform/kustomization.yaml:52 since it was authored, and the cluster has ZERO
# ImageRepository/ImagePolicy/ImageUpdateAutomation objects (measured). Its two controllers ARE
# installed and have idled for 43 days. Nothing is being torn down here; a path that was never
# taken is being formally closed, and renovate.json's `docker`/`kubernetes` managers — disabled
# purely to avoid fighting a controller that never ran — are switched on to fill the gap.
#
# ═══════════════════════════════════════════════════════════════════════════════════════════════
# THIS WORKFLOW MUST NOT BE ABLE TO SUCCEED SILENTLY
# ═══════════════════════════════════════════════════════════════════════════════════════════════
# A SKIPPED Gitea job reports `success` (CLAUDE.md §2), so "green" is not evidence this ran. Two
# guards:
#   * The preflight step FAILS HARD (exit 1) if RENOVATE_TOKEN is absent, rather than skipping.
#     A missing credential on a dependency bot is indistinguishable from "nothing to update", and
#     that is precisely how renovate.json stayed inert for months.
#   * The summary step records what ran into the job summary unconditionally.
# What this still does NOT give you is an alert when the SCHEDULE stops firing. See the handoff
# entry's "What I did NOT verify" — that gap is stated, not papered over.
#
# OPERATOR PREREQUISITE — ONE SECRET, NOT COMMITTED HERE:
#   `RENOVATE_TOKEN` — a Gitea access token for the bot account, scopes `write:repository`,
#   `read:user` and (since 2026-10-29) `read:package`. Set it as an Actions secret on this
#   repository. Nothing in this repo mints,
#   stores or references its value; it is consumed by name only.
#   Until it exists, this workflow FAILS LOUDLY on every scheduled run. That is intended: a
#   visible red is the correct state for "automation configured but not credentialed".
#
# THE FIRST RUN WILL WANT TO OPEN A LOT OF PRs. ~30 dependencies are behind. renovate.json caps the
# blast radius (`prConcurrentLimit: 5`, `prHourlyLimit: 2`), but run it manually with
# `dry_run: true` FIRST and read the log before letting the schedule loose. That is what
# workflow_dispatch's default is for.
name: renovate

on:
  schedule:
    # 08:15 UTC daily. renovate.json ALSO carries `"schedule": ["after 3am and before 6am"]` with
    # `"timezone": "America/New_York"`, and THAT inner schedule is authoritative — Renovate re-checks
    # it and DECLINES TO OPEN PRs outside it. So this cron must fire INSIDE the local window, not
    # merely near it.
    #
    # WAS `15 3 * * *`, WHICH NEVER WOULD HAVE WORKED (fixed 2026-10-18, before the first scheduled
    # run). Gitea Actions cron is UTC, so 03:15 UTC is 23:15 the PREVIOUS EVENING in New York --
    # 3h45m BEFORE the window opens, not "slightly ahead" of it as the original comment claimed.
    # Every nightly run would have started, logged "not within schedule", opened zero PRs and
    # exited SUCCESSFULLY. A green tick forever, and no updates ever: the exact "failure mode is a
    # green tick" shape this repo keeps getting burned by, and indistinguishable from "nothing
    # needed updating".
    #
    # THE WINDOW IN UTC MOVES WITH US DST, and a cron cannot follow it:
    #   EDT (UTC-4, Mar-Nov): local 03:00-06:00 == 07:00-10:00 UTC
    #   EST (UTC-5, Nov-Mar): local 03:00-06:00 == 08:00-11:00 UTC
    # 08:15 UTC is the only quarter-hour comfortably inside BOTH (04:15 EDT / 03:15 EST), so the
    # schedule keeps working across both switchovers without an edit. Do not "tidy" this back to an
    # early-morning-UTC value without redoing this arithmetic.
    - cron: "15 8 * * *"
  workflow_dispatch:
    inputs:
      dry_run:
        description: "Dry run (no PRs, no branches). Leave true for the first run."
        required: false
        default: "true"
      log_level:
        description: "Renovate LOG_LEVEL (info | debug)"
        required: false
        default: "info"

concurrency:
  # Never two Renovate runs at once: concurrent runs race on the same branches and can open
  # duplicate PRs. Not cancel-in-progress — a half-finished Renovate run can leave a branch pushed
  # with no PR, so let the first one finish.
  group: renovate
  cancel-in-progress: false

jobs:
  renovate:
    runs-on: ubuntu-latest
    # Renovate scans every manager across the whole repo; 40m is generous for this repo's size and
    # well under a runner's patience. Without a timeout a wedged run holds the `renovate`
    # concurrency group and silently blocks every subsequent scheduled run.
    timeout-minutes: 40
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Preflight - the token must exist, and its absence must be LOUD
        env:
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}
        run: |
          set -euo pipefail
          if [ -z "${RENOVATE_TOKEN:-}" ]; then
            echo "::error::RENOVATE_TOKEN is not set on this repository." >&2
            cat >&2 <<'MSG'

          Renovate cannot run without a Gitea access token, and this step fails rather than
          skipping ON PURPOSE: a skipped Gitea job reports `success`, so skipping here would make
          "dependency automation is not running" look exactly like "everything is up to date".
          That is the failure mode that let renovate.json sit inert in this repo for months while
          seven files claimed "Renovate maintains this pin".

          TO FIX: create a Gitea access token for the bot account with scopes
          `write:repository`, `read:user` and `read:package` (the last one lets Renovate read
          this repo's own images in the Gitea registry), then add it to this repository as the
          Actions secret RENOVATE_TOKEN. Do not commit it anywhere.
          MSG
            exit 1
          fi
          echo "RENOVATE_TOKEN is present (value not printed)."

      - name: Run Renovate
        uses: renovatebot/[email protected]
        with:
          # Pinned, and Renovate maintains this pin itself: renovate.json's enabledManagers
          # includes `github-actions`, and `helpers:pinGitHubActionDigests` is in its `extends`.
          # This is the one dependency in the repo whose updater is its own updater.
          # MUST match the file's real name. #79 renamed it to renovate.json5 and left this line
          # saying `renovate.json`; every scheduled run from 2026-10-18 then died in ~1s with
          # ENOENT before Renovate started, and nothing in the gate noticed. ci/lint.sh now
          # asserts that every `configurationFile:` here names a file that exists.
          configurationFile: renovate.json5
          token: ${{ secrets.RENOVATE_TOKEN }}
          # PINNED 2026-10-29. Unset, this action version runs Renovate `39` (action.yml
          # `renovate-version` default at v41.0.9), i.e. 39.264.0, and renovate.json5 uses
          # `managerFilePatterns` (>= 40.2.0): under 39.x validation fails with five errors and
          # the run stops at CONFIG_VALIDATION. #79 validated against `latest`, not this.
          renovate-version: 44.167.0
        env:
          # Self-hosted Gitea. `platform` + `endpoint` were the two values renovate.json's own
          # header said were "set at runtime by the operator's renovate runner" — this is that
          # runner, so they are set here rather than in the repo config, which keeps renovate.json
          # portable and free of this instance's URL.
          RENOVATE_PLATFORM: gitea
          RENOVATE_ENDPOINT: https://gitea.home.keithjackson.dev/api/v1
          RENOVATE_REPOSITORIES: Home-Network/home-network-k3s-impl
          # Renovate must never push to a protected branch; it works on its own branches and opens
          # PRs against this base. Stated explicitly rather than inherited, because this is the
          # property that keeps the whole mechanism inside CLAUDE.md §1's branch -> PR -> gate path.
          RENOVATE_BASE_BRANCHES: main
          RENOVATE_ONBOARDING: "false"
          RENOVATE_REQUIRE_CONFIG: "required"
          RENOVATE_DRY_RUN: ${{ github.event_name == 'workflow_dispatch' && inputs.dry_run == 'true' && 'full' || '' }}
          LOG_LEVEL: ${{ github.event_name == 'workflow_dispatch' && inputs.log_level || 'info' }}
          # ADDED 2026-10-29: registry read access for this repo's OWN images (toolbox,
          # agent-runner, conformance-runner — published by .gitea/workflows/images.yaml and
          # followed through `# renovate-digest:` markers). The Gitea registry answers 401 to
          # anonymous reads, and Renovate scopes the platform token to hostType `gitea`, which a
          # docker lookup never matches — so without this rule every digest lookup fails. Same
          # token; it therefore needs scope `read:package` in addition to the ones listed in the
          # preflight above. Gitea ignores the username for token auth (services/auth/basic.go).
          RENOVATE_HOST_RULES: '[{"hostType":"docker","matchHost":"gitea.home.keithjackson.dev","username":"renovate","password":"${{ secrets.RENOVATE_TOKEN }}"}]'

      - name: Summary
        if: always()
        run: |
          {
            echo "## Renovate"
            echo
            echo "- trigger: \`${{ github.event_name }}\`"
            echo "- dry run: \`${{ github.event_name == 'workflow_dispatch' && inputs.dry_run || 'false' }}\`"
            echo "- outcome: \`${{ job.status }}\`"
            echo
            echo "Renovate owns BOTH Helm chart bumps and container image tags here; Flux"
            echo "image-automation is deliberately disabled (platform/kustomization.yaml)."
            echo "Every change it proposes arrives as a pull request and must pass the merge gate."
          } >> "$GITHUB_STEP_SUMMARY"