Debug dry-run revealed why termix (and reloader/homepage/headlamp
8d ago) sit in "Pending Status Checks" indefinitely:
Marking 2 release(s) as pending, as they do not have a
releaseTimestamp and we're running with
minimumReleaseAgeBehaviour=timestamp-required
"depName": "ghcr.io/lukegus/termix"
"versions": ["release-1.11.2", "release-1.11.1"]
"check": "minimumReleaseAge"
ghcr.io OCI manifests for these images don't expose a release
timestamp Renovate can read, so the default `timestamp-required`
mode turns the 3-day stability gate into an INFINITE hold for
ghcr.io packages -- silently. PRs are never opened.
Switching to `timestamp-optional` (other supported value per Renovate
source: lib/config/options/index.ts) makes the gate best-effort: the
3-day window is still enforced for any package the datasource gives a
timestamp for; packages without a timestamp are allowed through.
Restores intended behavior.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Debug-level dry-run showed:
Dependency ghcr.io/lukegus/termix has unsupported/unversioned value
release-1.11.0 (versioning=loose)
Skipping ghcr.io/lukegus/termix because no currentDigest or pinDigests
`versioning: loose + extractVersion` doesn't work as intended here:
Renovate evaluates the currentValue (`release-1.11.0`) against the loose
parser BEFORE extractVersion is applied. loose can't parse a prefixed
value, so Renovate falls back to digest-based comparison; we don't pin
digests, so it silently skips and no PRs are ever opened. (Upstream has
v1.11.1, v1.11.2, and a major bump to release-2.3.2 since we deployed.)
Fix: use `versioning: regex:^release-(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)$`
which parses the whole tag including the `release-` prefix. The named
major/minor/patch groups let Renovate categorize bumps correctly so
the existing minor/patch automerge and major dashboard-approval rules
apply normally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Grows the Renovate pilot from 4 apps to a 16-app Tier 1 allowlist of
low-risk leaf apps (no DBs / schema migrations). packageRules keeps the
same 4-rule shape (default-deny, enable, automerge-minor/patch,
major-dashboard-approval) with the expanded package list in all three
Tier 1 rules.
Behavior changes:
- minimumReleaseAge "3 days" on the automerge rule: Renovate won't open
a minor/patch PR until the tag has been published upstream for 3 days
(stability gate; chosen over branch protection, which would disable
automerge entirely).
Image-string corrections vs. the planned list (Renovate matches the
exact image as written in the manifest; verified against the YAML):
- homepage -> ghcr.io/gethomepage/homepage (had no registry)
- reloader -> ghcr.io/stakater/reloader (had no registry)
- termix -> ghcr.io/lukegus/termix (had no registry)
Notes:
- registry.k8s.io/kube-state-metrics/kube-state-metrics is kept in the
list but currently matches nothing: ksm has no image in this repo
(only a Prometheus scrape target), so it's a harmless no-op until ksm
is ever deployed via a manifest here.
- ghcr.io/lukegus/termix uses a non-semver tag (release-1.11.0); watch
whether Renovate categorizes its updates as minor/patch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Self-hosted Renovate as a weekly CronJob (Sun 04:00 Europe/Budapest)
opening dependency-update PRs against admin/homelab-manifests on Gitea.
Pilot is deliberately narrow:
- Only the kubernetes + helm-values managers are enabled.
- Default-deny packageRule; only four images may update:
opengist, uptime-kuma, gokapi, cal.com.
- minor/patch -> PR with Gitea native auto-merge (platformAutomerge).
- major -> held for manual approval via Dependency Dashboard checkbox.
Image pinned to renovate/renovate:43.197.0 (the plain tag is the
minimal image; the -slim suffix was retired upstream after v37.440.x).
Stateless: no Service/Ingress/PVC. Read-only root FS with a 2Gi /tmp
emptyDir for git clones + cache. Secrets from existing renovate-secrets.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
DISABLE_SIGNUP=true blocks OIDC auto-register too (callback returns 'Signups are
currently disabled by the administrator'), so the first admin account can't be
created. Set DISABLE_SIGNUP=false just long enough for the admin to log in via
Authentik once (auto-registers + admin via SPARKY_FITNESS_ADMIN_EMAIL); will be
reverted to true right after.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Authentik application was created with slug 'sparky-fitness' (hyphen), so the
OIDC discovery document lives at /application/o/sparky-fitness/.well-known/...
The previous value (no hyphen) 404'd. Align the issuer URL with the actual slug.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SparkyFitness (https://github.com/CodeWithCJ/SparkyFitness) replaces wger on
workout.dooplex.hu / workout.home with native Authentik OIDC.
Components (sparkyfitness.yaml): dedicated postgres:15-alpine, server (3010,
/api/health), frontend nginx (root image, listens :80). PVCs sparkyfitness-postgres
+ sparkyfitness-uploads (Longhorn, backup labels). In-app OIDC, no forward-auth.
Deviations from the deploy spec, following upstream ground truth:
- In-container mount path for uploads is /app/SparkyFitnessServer/uploads (per the
upstream Helm chart values.yaml), not /app/uploads.
- Frontend root image (codewithcj/sparkyfitness) has 'listen 80;' hardcoded ->
NGINX_LISTEN_PORT=80, containerPort/Service 80.
- Image names use the docker-compose variants (codewithcj/sparkyfitness_server,
codewithcj/sparkyfitness); the upstream Helm chart uses -server/-frontend.
- All wger Deployments scaled to 0 (incl. celery worker/beat), not just
wger + wger-redis, so celery doesn't crashloop against the downed redis.
Secrets (outside git): sparky-oauth (client-id/client-secret, pre-existing) +
sparky-app (db + app-db creds, api-encryption-key, better-auth-secret).
wger is parked, not deleted: Deployments at 0, both Ingresses removed (ArgoCD
prune frees the hostnames); Services/ConfigMap/PVCs/CNPG DB kept for rollback.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>