fix(lidarr): unpin ImageRepository, keep Renovate out of image-automation #1552

2026-11-02T13:24:55Z

hermes-bot commented

2026-11-02 13:24:55 +00:00

What is broken

Per kubectl -n flux-system get imagerepository lidarr (observed 2026-11-02 ~13:15Z): spec.image: ghcr.io/linuxserver/lidarr@sha256:9fddcf5c…, message should not include a tag; remove ':9fddcf5c…'. Alertmanager shows FluxImageAutomationNotReady{name="lidarr"} active since 2026-11-02T12:50:14Z. All other 47 ImageRepositories report a successful scan. Lidarr itself keeps running on 3.1.6.5079-ls46; only its updates are stalled.

Cause

141b11a9 (Renovate, 2026-11-02 03:01Z) pinned the digest into the ImageRepository.
dab7c10e (2026-10-29) moved lidarr from lscr.io to ghcr.io/linuxserver/lidarr, but the renovate.json "Flux image automation already bumps these images" list still said lscr.io/linuxserver/lidarr.
Same failure mode as gitea-mcp in ffd24865 (2026-10-26).

Change

kubernetes/infrastructure/image-automation/lidarr.yaml: spec.image: ghcr.io/linuxserver/lidarr.
renovate.json: list entry lscr.io/linuxserver/lidarr → ghcr.io/linuxserver/lidarr (also covers the workload refs in apps/navidrome/lidarr.yaml).
renovate.json: ignorePaths += kubernetes/infrastructure/image-automation/**. The directory holds only ImageRepository/ImagePolicy/ImageUpdateAutomation objects, so Renovate has nothing to update there. A future gap in the list can then no longer break an ImageRepository.

Checked: the list now matches every ImageRepository image except the six gitea.renner.uno/gitea_admin/* ones (authentik-gate-sync, ci-backup-verify, cloudflare-lb-sync, kuma-sync, review-bot, secret-rotator). Those were missing before this PR too, and pinDigests: false already covers them for digest pins. With change 3 their ImageRepositories are safe either way. I left them alone because adding them is out of scope.

Validation

kubectl kustomize kubernetes/infrastructure/image-automation renders image: ghcr.io/linuxserver/lidarr.
renovate-config-validator: I could only run 37.440.7, an old cached npx version. It reports the same two errors on main and on this branch: flux/kubernetes.managerFilePatterns is unknown to that version. This PR adds no new errors.

After merge

Once Flux reconciles infrastructure, ImageRepository/lidarr should scan successfully (interval 1h, or right away on reconcile), turn Ready=True, and FluxImageAutomationNotReady{name="lidarr"} should resolve. If a newer -ls tag exists, ImageUpdateAutomation may then commit a lidarr bump. That bump is normal Flux image automation.

Not disruptive: no restart from this PR itself. renovate.json belongs to daedalus's area (Renovate). It is included here because the root cause sits in that list.

Hermes-Card: t_ea9730c7 (atlas)

Closes #1551 ## What is broken Per `kubectl -n flux-system get imagerepository lidarr` (observed 2026-11-02 ~13:15Z): `spec.image: ghcr.io/linuxserver/lidarr@sha256:9fddcf5c…`, message `should not include a tag; remove ':9fddcf5c…'`. Alertmanager shows `FluxImageAutomationNotReady{name="lidarr"}` active since 2026-11-02T12:50:14Z. All other 47 ImageRepositories report a successful scan. Lidarr itself keeps running on `3.1.6.5079-ls46`; only its updates are stalled. ## Cause - `141b11a9` (Renovate, 2026-11-02 03:01Z) pinned the digest into the ImageRepository. - `dab7c10e` (2026-10-29) moved lidarr from `lscr.io` to `ghcr.io/linuxserver/lidarr`, but the renovate.json "Flux image automation already bumps these images" list still said `lscr.io/linuxserver/lidarr`. - Same failure mode as gitea-mcp in `ffd24865` (2026-10-26). ## Change 1. `kubernetes/infrastructure/image-automation/lidarr.yaml`: `spec.image: ghcr.io/linuxserver/lidarr`. 2. `renovate.json`: list entry `lscr.io/linuxserver/lidarr` → `ghcr.io/linuxserver/lidarr` (also covers the workload refs in `apps/navidrome/lidarr.yaml`). 3. `renovate.json`: `ignorePaths` += `kubernetes/infrastructure/image-automation/**`. The directory holds only ImageRepository/ImagePolicy/ImageUpdateAutomation objects, so Renovate has nothing to update there. A future gap in the list can then no longer break an ImageRepository. Checked: the list now matches every ImageRepository image except the six `gitea.renner.uno/gitea_admin/*` ones (authentik-gate-sync, ci-backup-verify, cloudflare-lb-sync, kuma-sync, review-bot, secret-rotator). Those were missing before this PR too, and `pinDigests: false` already covers them for digest pins. With change 3 their ImageRepositories are safe either way. I left them alone because adding them is out of scope. ## Validation - `kubectl kustomize kubernetes/infrastructure/image-automation` renders `image: ghcr.io/linuxserver/lidarr`. - `renovate-config-validator`: I could only run 37.440.7, an old cached npx version. It reports the same two errors on `main` and on this branch: `flux/kubernetes.managerFilePatterns` is unknown to that version. This PR adds no new errors. ## After merge Once Flux reconciles `infrastructure`, `ImageRepository/lidarr` should scan successfully (interval 1h, or right away on reconcile), turn Ready=True, and `FluxImageAutomationNotReady{name="lidarr"}` should resolve. If a newer `-ls` tag exists, ImageUpdateAutomation may then commit a lidarr bump. That bump is normal Flux image automation. Not disruptive: no restart from this PR itself. renovate.json belongs to daedalus's area (Renovate). It is included here because the root cause sits in that list. Hermes-Card: t_ea9730c7 (atlas)

hermes-bot added 1 commit 2026-11-02 13:24:56 +00:00

fix(lidarr): unpin the ImageRepository and keep Renovate out of image-automation

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

e633b1a0c5

Renovate (141b11a9, 2026-11-02 03:01Z) pinned a digest into
ImageRepository/lidarr spec.image. image-reflector rejects that
(ImageURLInvalid: "should not include a tag"), so Flux stopped scanning
lidarr and FluxImageAutomationNotReady fires.

Renovate touched it because dab7c10e moved the ImageRepository and the
workload refs from lscr.io to ghcr.io/linuxserver/lidarr, while the
renovate.json list of Flux-managed images kept lscr.io/linuxserver/lidarr.

- lidarr.yaml: spec.image back to ghcr.io/linuxserver/lidarr.
- renovate.json: the list names ghcr.io/linuxserver/lidarr instead of
  lscr.io, so Renovate also leaves the workload refs in
  apps/navidrome/lidarr.yaml to Flux.
- renovate.json: ignorePaths gains kubernetes/infrastructure/image-automation/**.
  That directory holds only ImageRepository/ImagePolicy/ImageUpdateAutomation
  objects; no image ref in it is a deployable pin, and an ImageRepository
  spec.image must never carry a tag or digest. This is the second time
  in a week (gitea-mcp, ffd24865) a list gap let Renovate pin one.

Closes #1551

k.renner merged commit 27a34fa5f5 into main

2026-11-02 14:01:54 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#1552