Privacy-focused, client-side PDF toolkit deployed into the office-system
namespace alongside OnlyOffice. Stateless (no DB/PVC); nginx-internal
ingress with HU geo-restriction and letsencrypt-prod TLS. Auto-synced by
the existing `office` ArgoCD Application.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Was Sun 04:00; now Sat 02:00 so Renovate's wave lands at the start of
the weekend instead of the end. If an auto-merged update breaks
something, Viktor has the full weekend to troubleshoot.
`0 2 * * 6` = Saturday 02:00 in Europe/Budapest (the CronJob already
sets timeZone, so this is wall-clock local).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the security-flagged `minimumReleaseAge: 0` bypass with a
proper datasource swap.
Why: ghcr.io OCI manifests for ghcr.io/lukegus/termix don't expose a
release timestamp, so Renovate's default `timestamp-required` mode
holds updates indefinitely. The previous fix (zeroing the gate) was
flagged as a supply-chain control regression -- correctly, since it
weakens the stability protection for that package.
Cleaner fix: point Renovate's version lookup at the upstream GitHub
Releases (Termix-SSH/Termix per the OCI source label) where timestamps
ARE published. The 3-day gate then works for termix the same way it
works for other packages with intact timestamps. Renovate still
updates the same image -- the manager extracts ghcr.io/lukegus/termix
from termix.yaml and writes the new tag back; only the version-source
lookup is redirected. The ghcr.io registry hosts every release-X.Y.Z
tag (verified release-2.3.2 present), so the writeback target stays
valid.
Major bumps (1.x -> 2.x) continue to queue for dashboard approval via
the global major rule.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Last commit's global `minimumReleaseAgeBehaviour: timestamp-optional` did
two unwanted things:
1) Dry-run showed 0 "Would commit" branches (was 33 before). The flag
appears to alter Renovate's filtering more broadly than expected and
is not the right knob here.
2) Automated security review correctly flagged the global form as
fail-open: a missing timestamp on ANY package would bypass the
stability gate, weakening supply-chain protection across the fleet.
Narrow fix instead:
- Revert the global setting (back to default `timestamp-required`).
- Add `minimumReleaseAge: "0 days"` ONLY to the termix packageRule.
ghcr.io OCI manifests for ghcr.io/lukegus/termix don't expose a
release timestamp Renovate can read, so the global 3-day gate would
otherwise hold updates indefinitely (this is the same class of issue
that's been keeping reloader/homepage/headlamp on "Pending Status
Checks" for 8+ days). Major bumps still gated by the global major
rule (`dependencyDashboardApproval: true`).
Other ghcr.io packages with the same issue (reloader, homepage, headlamp)
remain on the dashboard's "Pending Status Checks" list and can be
force-approved per-update via the checkbox UX. That's a slower but safer
manual-approval path that preserves the supply-chain gate's intent.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
admin
Renovate Bot