fix(ical-proxy): pin the image so a new build actually rolls #490

2026-08-13T19:39:18Z

claude-bot commented

2026-08-13 19:39:18 +00:00

:latest never rolls. The tag moves when a build publishes, but nothing tells the Deployment — the pod template is unchanged, so Kubernetes has no reason to replace anything.

Nothing else covers it either. This image is deliberately not enrolled in Flux image automation. kubernetes/infrastructure/image-automation/README.md lists ghcr.io/konairius/ical-proxy as having "only main, latest, and main-<sha> commit builds; no release tags", so no ImagePolicy watches it.

Result: the two pods have been running a 21-day-old image while :latest moved underneath them, and the only way to pick up a new build was a manual kubectl rollout restart — which leaves no record anywhere.

Pinning makes the rollout a git change. Flux applies the new pod template, Kubernetes rolls it, and what is running becomes recoverable from this repo instead of "whatever :latest meant the last time a pod happened to restart".

main-99a912b is the merge of konairius/ical-proxy#12, which adds the summary_match / summary_replace parameters. The waste calendar needs them: the feed repeats the whole calendar's name on every event, so a bin day arrives as Altpapier| Abfuhrkalender - Landkreis Amberg-Sulzbach, and no consumer can shorten it afterwards.

Verified before pinning:

CI on the merge commit: build, test, lint, static-analysis, docker all green
The tag exists in the registry — ghcr.io/v2/konairius/ical-proxy/tags/list returns main-99a912b

Bumping this tag is now a manual, reviewed edit. Format is main-<short-sha>, from docker/metadata-action type=sha with the branch as prefix.

This alone does not change the panel. The summary_match parameter still has to go onto the remote_calendar config entry's URL, which lives in HA's config entries rather than in git.

`:latest` never rolls. The tag moves when a build publishes, but nothing tells the Deployment — the pod template is unchanged, so Kubernetes has no reason to replace anything. Nothing else covers it either. This image is deliberately **not** enrolled in Flux image automation. `kubernetes/infrastructure/image-automation/README.md` lists `ghcr.io/konairius/ical-proxy` as having *"only `main`, `latest`, and `main-<sha>` commit builds; no release tags"*, so no ImagePolicy watches it. Result: the two pods have been running a **21-day-old image** while `:latest` moved underneath them, and the only way to pick up a new build was a manual `kubectl rollout restart` — which leaves no record anywhere. Pinning makes the rollout a git change. Flux applies the new pod template, Kubernetes rolls it, and what is *running* becomes recoverable from this repo instead of "whatever `:latest` meant the last time a pod happened to restart". `main-99a912b` is the merge of [konairius/ical-proxy#12](https://github.com/konairius/ical-proxy/pull/12), which adds the `summary_match` / `summary_replace` parameters. The waste calendar needs them: the feed repeats the whole calendar's name on every event, so a bin day arrives as `Altpapier| Abfuhrkalender - Landkreis Amberg-Sulzbach`, and no consumer can shorten it afterwards. Verified before pinning: - CI on the merge commit: `build`, `test`, `lint`, `static-analysis`, `docker` all green - The tag exists in the registry — `ghcr.io/v2/konairius/ical-proxy/tags/list` returns `main-99a912b` Bumping this tag is now a manual, reviewed edit. Format is `main-<short-sha>`, from `docker/metadata-action` `type=sha` with the branch as prefix. **This alone does not change the panel.** The `summary_match` parameter still has to go onto the `remote_calendar` config entry's URL, which lives in HA's config entries rather than in git.

claude-bot added 1 commit 2026-08-13 19:39:18 +00:00

fix(ical-proxy): pin the image so a new build actually rolls

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

Details

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

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

a2de5b5f56

:latest never rolls. The tag moves when a build publishes, but nothing
tells the Deployment: the pod template is unchanged, so Kubernetes has
no reason to replace anything.

Nothing else covers it either. This image is deliberately not enrolled in
Flux image automation — kubernetes/infrastructure/image-automation/README.md
lists ghcr.io/konairius/ical-proxy as having "only main, latest, and
main-<sha> commit builds; no release tags", so no ImagePolicy watches it.
The two pods have been running a 21-day-old image while :latest moved
underneath them, and the only way to pick up a new build was a manual
restart, which leaves no record anywhere.

Pinning makes the rollout a git change. Flux applies the new pod
template, Kubernetes rolls it, and what is RUNNING becomes recoverable
from this repo instead of "whatever :latest meant the last time a pod
happened to restart".

main-99a912b is the merge of konairius/ical-proxy#12, which adds the
summary_match and summary_replace parameters. The waste calendar needs
them to strip "| Abfuhrkalender - Landkreis Amberg-Sulzbach" from every
collection — the feed repeats the whole calendar's name on each event,
and no consumer can shorten it after the fact.

Bumping this tag is now a manual, reviewed edit. Format is
main-<short-sha>, from docker/metadata-action type=sha with the branch
as prefix.

k.renner merged commit 7a80df3cfc into master

2026-08-13 19:40:59 +00:00

k.renner referenced this issue from a commit

2026-08-13 19:41:01 +00:00

Merge pull request 'fix(ical-proxy): pin the image so a new build actually rolls' (#490) from pin-ical-proxy-image into master

review-bot reviewed

2026-08-13 19:41:07 +00:00

review-bot left a comment

🤖 Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit a2de5b5f569a5f1525efc69449f2c985528c5859.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR pins the ical-proxy image from :latest to :main-99a912b (a commit-specific build), fixing a deployment automation issue where pod restarts never pick up new upstream builds. The diagnosis is correct, the solution is appropriate for this project's infrastructure, and the implementation is sound.

🟢 Nits

Comment block length — kubernetes/apps/ical-proxy/deployment.yaml:10-35 contains 16 lines of explanation. This is thorough and justified (the issue is subtle), and mirrors the style of similar infrastructure decisions elsewhere in the repo (e.g., kubernetes/apps/trmnl/renderer.yaml:235-242). No change needed.

Tests

This is a deployment configuration change with no unit tests needed. The upstream image passed CI on the merge commit per the PR body. The deployment has liveness and readiness probes that will validate the image works on rollout.

Recommendation

Looks reasonable — no blocking issues; the pinning strategy is correct and well-documented.

🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `a2de5b5f569a5f1525efc69449f2c985528c5859`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR pins the ical-proxy image from `:latest` to `:main-99a912b` (a commit-specific build), fixing a deployment automation issue where pod restarts never pick up new upstream builds. The diagnosis is correct, the solution is appropriate for this project's infrastructure, and the implementation is sound. ## 🟢 Nits **Comment block length** — `kubernetes/apps/ical-proxy/deployment.yaml:10-35` contains 16 lines of explanation. This is thorough and justified (the issue is subtle), and mirrors the style of similar infrastructure decisions elsewhere in the repo (e.g., `kubernetes/apps/trmnl/renderer.yaml:235-242`). No change needed. ## Tests This is a deployment configuration change with no unit tests needed. The upstream image passed CI on the merge commit per the PR body. The deployment has liveness and readiness probes that will validate the image works on rollout. ## Recommendation Looks reasonable — no blocking issues; the pinning strategy is correct and well-documented.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#490