Five pipeline steps sat on two stale tags. All now point at 2026-08-10, the newest dated tag in gitea_admin/ci-k8s.
File
Was
Now
.woodpecker/e2e-test.yml:7
2026-05-01
2026-08-10
.woodpecker/e2e.yml:33
2026-05-01
2026-08-10
.woodpecker/alert-monitor.yml:45
2026-05-01
2026-08-10
.woodpecker/issue-fix.yml:52
2026-05-01
2026-08-10
.woodpecker/ci-manifests-test.yml:63,243
2026-07-30
2026-08-10
The issue only named the four 2026-05-01 pins; ci-manifests-test.yml went stale in the two weeks since it was filed, so it is included rather than left as the next issue.
2026-08-10 is confirmed head: it is the newest dated tag in the registry's tag list, and it shares a digest with :latest (sha256:0019f264...).
Verification
The issue asked that each bump be verified rather than shipped under a green run that never touched it. Pipeline 5340 (e2e-test on this branch) ran the new image end to end and passed both steps.
That run is not just evidence for e2e-test.yml. The four ci-k8s steps in question run only three scripts between them, and the green run exercised every binary they need:
Script
Needs from the image
Exercised by 5340
scripts/ci/fetch-kubeconfig.sh
bash, sops, aws-cli
yes
kubernetes/e2e-test.sh
bash, curl, flux, kubectl, openssl, velero
yes
scripts/ci/make-diag-kubeconfig.sh (issue-fix)
bash, kubectl
yes
kubectl get --raw (alert-monitor)
bash, kubectl
yes
e2e.yml's ci-k8s step runs the same two commands as e2e-test.yml, so it is covered directly.
Not run:alert-monitor and issue-fix end to end. Both have real side effects — alert-monitor files Gitea issues, issue-fix opens a PR — so triggering them purely as an image smoke test would leave litter behind. Their ci-k8s steps add no tool beyond the table above. Their next scheduled cron is the real test.
Why it matters
Only one commit touched ci/images/k8s/ between the two tags: 2feec4b1, which pinned the alpine base by digest, added checksum verification for talosctl/kubectl/velero, replaced curl | bash for flux with a pinned verified tarball, and pinned KUBECTL_VERSION. So the delta is a hardening change plus whatever the tool versions moved to — exactly the kind of thing that should not diverge across pipelines by accident.
A stale pin also eventually points at a garbage-collected tag.
Closes #461.
Five pipeline steps sat on two stale tags. All now point at `2026-08-10`, the newest dated tag in `gitea_admin/ci-k8s`.
| File | Was | Now |
|---|---|---|
| `.woodpecker/e2e-test.yml:7` | `2026-05-01` | `2026-08-10` |
| `.woodpecker/e2e.yml:33` | `2026-05-01` | `2026-08-10` |
| `.woodpecker/alert-monitor.yml:45` | `2026-05-01` | `2026-08-10` |
| `.woodpecker/issue-fix.yml:52` | `2026-05-01` | `2026-08-10` |
| `.woodpecker/ci-manifests-test.yml:63,243` | `2026-07-30` | `2026-08-10` |
The issue only named the four `2026-05-01` pins; `ci-manifests-test.yml` went stale in the two weeks since it was filed, so it is included rather than left as the next issue.
`2026-08-10` is confirmed head: it is the newest dated tag in the registry's tag list, and it shares a digest with `:latest` (`sha256:0019f264...`).
## Verification
The issue asked that each bump be verified rather than shipped under a green run that never touched it. Pipeline **5340** (`e2e-test` on this branch) ran the new image end to end and **passed both steps**.
That run is not just evidence for `e2e-test.yml`. The four ci-k8s steps in question run only three scripts between them, and the green run exercised every binary they need:
| Script | Needs from the image | Exercised by 5340 |
|---|---|---|
| `scripts/ci/fetch-kubeconfig.sh` | bash, sops, aws-cli | yes |
| `kubernetes/e2e-test.sh` | bash, curl, flux, kubectl, openssl, velero | yes |
| `scripts/ci/make-diag-kubeconfig.sh` (issue-fix) | bash, kubectl | yes |
| `kubectl get --raw` (alert-monitor) | bash, kubectl | yes |
`e2e.yml`'s ci-k8s step runs the *same two commands* as `e2e-test.yml`, so it is covered directly.
**Not run:** `alert-monitor` and `issue-fix` end to end. Both have real side effects — alert-monitor files Gitea issues, issue-fix opens a PR — so triggering them purely as an image smoke test would leave litter behind. Their ci-k8s steps add no tool beyond the table above. Their next scheduled cron is the real test.
## Why it matters
Only one commit touched `ci/images/k8s/` between the two tags: `2feec4b1`, which pinned the alpine base by digest, added checksum verification for talosctl/kubectl/velero, replaced `curl | bash` for flux with a pinned verified tarball, and pinned `KUBECTL_VERSION`. So the delta is a hardening change plus whatever the tool versions moved to — exactly the kind of thing that should not diverge across pipelines by accident.
A stale pin also eventually points at a garbage-collected tag.
Closes#461.
Five pipeline steps pinned ci-k8s at two stale tags: e2e-test.yml,
e2e.yml, alert-monitor.yml and issue-fix.yml at 2026-05-01, and
ci-manifests-test.yml at 2026-07-30. 2026-08-10 is the newest dated tag
in gitea_admin/ci-k8s and shares a digest with :latest
(sha256:0019f264...), so all five now run the same image the build
pipeline last produced.
A stale pin eventually points at a garbage-collected tag, and the split
had no deliberate reason behind it.
Co-Authored-By: Claude Bot <claude-bot@renner.uno>
🤖Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit 632e092363235df7fdf9015726ea2bcec5e481db.
Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.
Summary
This PR updates stale ci-k8s image tag pins from 2026-05-01 and 2026-07-30 to 2026-08-10 across 5 Woodpecker pipeline files. The changes are minimal, consistent, and well-verified — pipeline 5340 (e2e-test) ran the new image and passed both steps, confirming all required binaries are present.
🔴 Blocking
No blocking issues identified.
🟡 Suggestions
The PR body is exceptionally thorough and demonstrates good discipline: it documents which scripts exercise which binaries, explains why alert-monitor and issue-fix weren't run end-to-end (side effects), and confirms the tag is the latest available. The verification approach is sound and the changes address a real maintenance concern (stale tags becoming eligible for garbage collection).
Tests
The change is adequately tested. Pipeline 5340 (e2e-test) successfully ran with the new 2026-08-10 image and verified that all key dependencies (bash, sops, aws-cli, curl, flux, kubectl, openssl, velero) are present. The verification table in the PR body shows that e2e-test exercises every binary used by the other updated pipeline steps.
Recommendation
Looks reasonable — no blocking issues; changes are minor CI version bumps with solid verification.
🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `632e092363235df7fdf9015726ea2bcec5e481db`.
> Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review.
---
## Summary
This PR updates stale ci-k8s image tag pins from `2026-05-01` and `2026-07-30` to `2026-08-10` across 5 Woodpecker pipeline files. The changes are minimal, consistent, and well-verified — pipeline 5340 (e2e-test) ran the new image and passed both steps, confirming all required binaries are present.
## 🔴 Blocking
No blocking issues identified.
## 🟡 Suggestions
The PR body is exceptionally thorough and demonstrates good discipline: it documents which scripts exercise which binaries, explains why alert-monitor and issue-fix weren't run end-to-end (side effects), and confirms the tag is the latest available. The verification approach is sound and the changes address a real maintenance concern (stale tags becoming eligible for garbage collection).
## Tests
The change is adequately tested. Pipeline 5340 (e2e-test) successfully ran with the new `2026-08-10` image and verified that all key dependencies (bash, sops, aws-cli, curl, flux, kubectl, openssl, velero) are present. The verification table in the PR body shows that e2e-test exercises every binary used by the other updated pipeline steps.
## Recommendation
Looks reasonable — no blocking issues; changes are minor CI version bumps with solid verification.
<!-- pr-review:sha=632e092363235df7fdf9015726ea2bcec5e481db -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #461.
Five pipeline steps sat on two stale tags. All now point at
2026-08-10, the newest dated tag ingitea_admin/ci-k8s..woodpecker/e2e-test.yml:72026-05-012026-08-10.woodpecker/e2e.yml:332026-05-012026-08-10.woodpecker/alert-monitor.yml:452026-05-012026-08-10.woodpecker/issue-fix.yml:522026-05-012026-08-10.woodpecker/ci-manifests-test.yml:63,2432026-07-302026-08-10The issue only named the four
2026-05-01pins;ci-manifests-test.ymlwent stale in the two weeks since it was filed, so it is included rather than left as the next issue.2026-08-10is confirmed head: it is the newest dated tag in the registry's tag list, and it shares a digest with:latest(sha256:0019f264...).Verification
The issue asked that each bump be verified rather than shipped under a green run that never touched it. Pipeline 5340 (
e2e-teston this branch) ran the new image end to end and passed both steps.That run is not just evidence for
e2e-test.yml. The four ci-k8s steps in question run only three scripts between them, and the green run exercised every binary they need:scripts/ci/fetch-kubeconfig.shkubernetes/e2e-test.shscripts/ci/make-diag-kubeconfig.sh(issue-fix)kubectl get --raw(alert-monitor)e2e.yml's ci-k8s step runs the same two commands ase2e-test.yml, so it is covered directly.Not run:
alert-monitorandissue-fixend to end. Both have real side effects — alert-monitor files Gitea issues, issue-fix opens a PR — so triggering them purely as an image smoke test would leave litter behind. Their ci-k8s steps add no tool beyond the table above. Their next scheduled cron is the real test.Why it matters
Only one commit touched
ci/images/k8s/between the two tags:2feec4b1, which pinned the alpine base by digest, added checksum verification for talosctl/kubectl/velero, replacedcurl | bashfor flux with a pinned verified tarball, and pinnedKUBECTL_VERSION. So the delta is a hardening change plus whatever the tool versions moved to — exactly the kind of thing that should not diverge across pipelines by accident.A stale pin also eventually points at a garbage-collected tag.
🤖 Automated review — model
claude-haiku-4-5-20251001(complexity: trivial), commit632e092363235df7fdf9015726ea2bcec5e481db.Summary
This PR updates stale ci-k8s image tag pins from
2026-05-01and2026-07-30to2026-08-10across 5 Woodpecker pipeline files. The changes are minimal, consistent, and well-verified — pipeline 5340 (e2e-test) ran the new image and passed both steps, confirming all required binaries are present.🔴 Blocking
No blocking issues identified.
🟡 Suggestions
The PR body is exceptionally thorough and demonstrates good discipline: it documents which scripts exercise which binaries, explains why alert-monitor and issue-fix weren't run end-to-end (side effects), and confirms the tag is the latest available. The verification approach is sound and the changes address a real maintenance concern (stale tags becoming eligible for garbage collection).
Tests
The change is adequately tested. Pipeline 5340 (e2e-test) successfully ran with the new
2026-08-10image and verified that all key dependencies (bash, sops, aws-cli, curl, flux, kubectl, openssl, velero) are present. The verification table in the PR body shows that e2e-test exercises every binary used by the other updated pipeline steps.Recommendation
Looks reasonable — no blocking issues; changes are minor CI version bumps with solid verification.