[alert] FluxImageAutomationNotReady (cluster) #1551

Closed
opened 2026-11-02 13:21:16 +00:00 by hermes-bot · 1 comment
Member

What is firing: FluxImageAutomationNotReady, warning, flux-system ImageRepository/lidarr, since 2026-11-02T12:50Z (object not Ready since 10:47:25Z).

Evidence

  • kubectl -n flux-system get imagerepository lidarr -o yaml: spec.image: ghcr.io/linuxserver/lidarr@sha256:9fddcf5c…; condition Ready=False reason=ImageURLInvalid: "should not include a tag; remove ':9fddcf5c…'". Last successful scan 2026-11-02T10:24:58Z.
  • git show 141b11a9 (Renovate Bot, 2026-11-02 03:01Z, "chore(deps): pin ghcr.io/linuxserver/lidarr docker tag to 9fddcf5"): changes kubernetes/infrastructure/image-automation/lidarr.yaml image: ghcr.io/linuxserver/lidarr → ...@sha256:9fddcf5c…. Commit is on main.
  • dab7c10e (2026-10-29, "fix(lidarr): scan ghcr.io directly instead of lscr.io") moved the ImageRepository to ghcr.io/linuxserver/lidarr, but the Renovate "Flux image automation already bumps these images" disable rule in renovate.json still lists lscr.io/linuxserver/lidarr, not ghcr.io/linuxserver/lidarr.

Root cause (verified): the disable list fell out of sync with the ImageRepository image after the lscr→ghcr move, so Renovate's pinDigest rule treated the ImageRepository's spec.image as a container image and pinned a digest; Flux rejects digests in ImageRepository.spec.image. Lidarr itself keeps running; only its image updates have stopped.

Where to fix it

  • kubernetes/infrastructure/image-automation/lidarr.yaml: spec.image back to ghcr.io/linuxserver/lidarr.
  • renovate.json: replace lscr.io/linuxserver/lidarr with ghcr.io/linuxserver/lidarr in the disabled-packages list (Renovate config is daedalus's domain if a hand-off is preferred). Worth checking the list against all ImageRepository images in one pass, and whether Renovate should skip ImageRepository.spec.image in general.

Filed automatically by the Hermes alert-monitor job (2026-11-02) for the atlas expert, whose kanban card takes it to a fix PR.

**What is firing**: `FluxImageAutomationNotReady`, warning, `flux-system` ImageRepository/lidarr, since 2026-11-02T12:50Z (object not Ready since 10:47:25Z). **Evidence** - `kubectl -n flux-system get imagerepository lidarr -o yaml`: `spec.image: ghcr.io/linuxserver/lidarr@sha256:9fddcf5c…`; condition `Ready=False reason=ImageURLInvalid`: "should not include a tag; remove ':9fddcf5c…'". Last successful scan 2026-11-02T10:24:58Z. - `git show 141b11a9` (Renovate Bot, 2026-11-02 03:01Z, "chore(deps): pin ghcr.io/linuxserver/lidarr docker tag to 9fddcf5"): changes `kubernetes/infrastructure/image-automation/lidarr.yaml` `image: ghcr.io/linuxserver/lidarr` → `...@sha256:9fddcf5c…`. Commit is on `main`. - `dab7c10e` (2026-10-29, "fix(lidarr): scan ghcr.io directly instead of lscr.io") moved the ImageRepository to `ghcr.io/linuxserver/lidarr`, but the Renovate "Flux image automation already bumps these images" disable rule in `renovate.json` still lists `lscr.io/linuxserver/lidarr`, not `ghcr.io/linuxserver/lidarr`. **Root cause** (verified): the disable list fell out of sync with the ImageRepository image after the lscr→ghcr move, so Renovate's pinDigest rule treated the ImageRepository's `spec.image` as a container image and pinned a digest; Flux rejects digests in `ImageRepository.spec.image`. Lidarr itself keeps running; only its image updates have stopped. **Where to fix it** - `kubernetes/infrastructure/image-automation/lidarr.yaml`: `spec.image` back to `ghcr.io/linuxserver/lidarr`. - `renovate.json`: replace `lscr.io/linuxserver/lidarr` with `ghcr.io/linuxserver/lidarr` in the disabled-packages list (Renovate config is daedalus's domain if a hand-off is preferred). Worth checking the list against all ImageRepository images in one pass, and whether Renovate should skip `ImageRepository.spec.image` in general. --- <!-- alert-monitor:fingerprint=20156f16d88c9a85 --> _Filed automatically by the Hermes alert-monitor job (2026-11-02) for the `atlas` expert, whose kanban card takes it to a fix PR._
hermes-bot added the atlas label 2026-11-02 13:21:16 +00:00
Author
Member

Hermes kanban card t_ea9730c7 for this issue is assigned to atlas.

Hermes kanban card `t_ea9730c7` for this issue is assigned to atlas. <!-- hermes-kanban-card:t_ea9730c7 -->
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: konairius/homelab#1551