Three coordinated changes, all surfaced by the question "will Renovate
track the manually-bumped packages going forward":
1) Delete `felhom-system/` directory (4 files).
These were never the source of truth -- the `felhom` ArgoCD app
pulls from `felhom.eu`, path `manifests`. The copies in this repo
fell out of sync over time and were misleading. Renovate was about
to start opening DEAD PRs against them (the customManager below
targeted `felhom-system/umami.yaml`). Removing the directory is the
cleanest fix; manual bumps for the real felhom-system manifests go
into the felhom.eu repo.
2) Fix plex inline `# renovate:` comment in helm/plex/values.yaml.
It referenced `datasource=custom.plex` but no such customDatasource
exists in the config -- Renovate would silently skip plex. Switched
to the standard docker datasource with regex versioning that parses
`1.X.Y.Z-<hash>` (4 segments + git short-hash suffix, same pattern
approach as servarr and termix).
3) Remove the now-obsolete umami customManager + packageRule.
The customManager was for the `postgresql-vX.Y.Z` tag form we've
abandoned -- the real felhom.eu deployment is on `3.1.0` (plain
semver). The packageRule disabled the kubernetes manager for the
umami image to silence its failure on `postgresql-vX.Y.Z`; not
needed since the default versioning handles `3.X.Y` fine. (Moot
anyway since Renovate doesn't watch felhom.eu -- but cleanup
reduces config noise.)
After this PR, Renovate's effective tracking:
- servarr (sonarr/radarr/prowlarr) -> YES (customManager)
- plex -> YES (inline comment, docker)
- termix -> YES (customManager)
- umami / filebrowser in felhom.eu -> NO (different repo, manual)
- all standard semver/named tags in homelab-manifests -> YES (defaults)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- sonarr version-4.0.16.2944 -> version-4.0.17.2952 (patch within 4.0.x)
- radarr×2 version-6.0.4.10291 -> version-6.1.1.10360 (minor within 6.x)
- prowlarr version-2.3.0.5236 -> version-2.3.5.5327 (patch within 2.3.x)
- plex 1.43.0.10467-... -> 1.43.2.10687-... (patch within 1.43.x)
All four were stuck because of tag-format issues that I addressed in
PR #82 (servarr customManager) / PR #83. Renovate isn't auto-creating
the PRs yet (DH rate-limit), so doing them manually so version-checker
clears.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Several images were showing as outdated in version-checker / unhandled by
Renovate. Each had a distinct cause; this PR fixes the auto-tractable ones.
1) admin-system/renovate.yaml: bump `app.kubernetes.io/version` labels
`43.197.0 -> 43.209.3` (3 occurrences) to match the live image.
Renovate's own self-update PR bumped the image tag but left the
labels stale; the version-checker widget appears to read the label.
Long-term, this label will drift again on each self-update -- worth
a customManager later if it becomes a recurring annoyance.
2) admin-system/renovate.yaml: add a customManager + packageRule pair
for linuxserver servarr apps. Tag pattern is `version-X.Y.Z.B`
(4 segments + `version-` prefix) which the kubernetes manager's
default docker versioning rejects at the pre-check, same failure
class as termix. Regex versioning parses the prefixed 4-segment
form; the same customManager handles prowlarr/radarr/sonarr (depName
captured from the regex). kubernetes-manager extraction for these
three depnames is disabled via packageRule so the dashboard isn't
cluttered with the failing fallback.
3) nextcloud-system/nextcloud.yaml: add
`match-regex.version-checker.io/nextcloud: '^\d+\.\d+\.\d+-apache$'`
so version-checker doesn't treat the bare `33.0.5` server tag as a
newer version of our `33.0.5-apache` image. The widget was showing
`33.0.5-apache -> 33.0.5` -- false positive; image is already current.
4) helm/plex/values.yaml: tighten the version-checker regex from
`^\d+\.\d+\.\d+\.\d+-.*$` to `^\d+\.\d+\.\d+\.\d+-[a-f0-9]+$` so
per-arch tags (`-armhf`, `-arm64`, ...) are excluded. The widget
was showing an `-armhf` tag as "newer" than our x86_64 install.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>