ci(kaniko): move the remaining eight builds to the maintained fork #665

2026-08-27T11:03:41Z

claude-bot commented

2026-08-27 11:03:41 +00:00

Lauf 6861 hat beantwortet, wofür der gestaffelte erste Schritt da war.

build-alpine-jq lief auf v1.25.18 der Fork durch — Rootfs entpackt, RUN ausgeführt, beide Ziele gepusht:

Pushing image to gitea.renner.uno/gitea_admin/alpine-jq:2026-08-27
Pushed ...@sha256:a430c9c6aa100c0c7df506fbe39315652872b9f1815b8ed22c33bb424913bf1d
Pushing image to gitea.renner.uno/gitea_admin/alpine-jq:latest

— während die sieben unangetasteten kaniko-Steps im selben Lauf grün blieben. Genau die Gegenprobe, für die die Staffelung gedacht war.

Damit ziehen die übrigen sieben Steps plus der eine in ci-claude-refresh.yml nach. Es ändern sich ausschließlich die image:-Zeilen — keine Flags, keine Commands, keine Credentials. Danach gibt es in den Pipelines keine gcr.io/kaniko-project-Referenz mehr.

Den Step-Kommentar aus dem ersten Commit habe ich entfernt. Er beschrieb einen Migrationszustand, den es nicht mehr gibt — und ein Kommentar, der seine eigene Lage überlebt, ist genau, wie der Velero-Schedule dazu kam zu behaupten, in einem Namespace gebe es kein CNPG-Cluster. Der haltbare Teil steht jetzt im Dateikopf: warum das kaniko-Image nicht Googles ist und warum der Pin über der Version liegt, bei der deren Repo endete.

Nebenbefund: kubernetes/infrastructure/admission-policies/woodpecker-ci-restrict.yaml nannte gcr.io/kaniko-project/executor als das Image, gegen das die Ausnahme verifiziert wurde. Die Policy matcht in Wahrheit nur auf das buildx-Plugin-Image und nie auf kaniko — der Tausch brauchte deshalb keine Policy-Änderung. Genau deshalb war der veraltete Verweis in der Prosa leicht zu übersehen; korrigiert.

Closes #552

Lauf 6861 hat beantwortet, wofür der gestaffelte erste Schritt da war. `build-alpine-jq` lief auf v1.25.18 der Fork durch — Rootfs entpackt, `RUN` ausgeführt, beide Ziele gepusht: ``` Pushing image to gitea.renner.uno/gitea_admin/alpine-jq:2026-08-27 Pushed ...@sha256:a430c9c6aa100c0c7df506fbe39315652872b9f1815b8ed22c33bb424913bf1d Pushing image to gitea.renner.uno/gitea_admin/alpine-jq:latest ``` — während die sieben unangetasteten kaniko-Steps im selben Lauf grün blieben. Genau die Gegenprobe, für die die Staffelung gedacht war. Damit ziehen die übrigen sieben Steps plus der eine in `ci-claude-refresh.yml` nach. Es ändern sich ausschließlich die `image:`-Zeilen — keine Flags, keine Commands, keine Credentials. Danach gibt es in den Pipelines keine `gcr.io/kaniko-project`-Referenz mehr. **Den Step-Kommentar aus dem ersten Commit habe ich entfernt.** Er beschrieb einen Migrationszustand, den es nicht mehr gibt — und ein Kommentar, der seine eigene Lage überlebt, ist genau, wie der Velero-Schedule dazu kam zu behaupten, in einem Namespace gebe es kein CNPG-Cluster. Der haltbare Teil steht jetzt im Dateikopf: warum das kaniko-Image nicht Googles ist und warum der Pin über der Version liegt, bei der deren Repo endete. **Nebenbefund:** `kubernetes/infrastructure/admission-policies/woodpecker-ci-restrict.yaml` nannte `gcr.io/kaniko-project/executor` als das Image, gegen das die Ausnahme verifiziert wurde. Die Policy matcht in Wahrheit nur auf das buildx-Plugin-Image und nie auf kaniko — der Tausch brauchte deshalb keine Policy-Änderung. Genau deshalb war der veraltete Verweis in der Prosa leicht zu übersehen; korrigiert. Closes #552

claude-bot added 1 commit 2026-08-27 11:03:42 +00:00

ci(kaniko): move the remaining eight builds to the maintained fork

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

Details

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

Details

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

Details

ci/woodpecker/push/build-ci-images Pipeline was successful

Details

60f231f839

Pipeline 6861 answered the question the staged first step was there to ask.
build-alpine-jq ran on the fork's v1.25.18, unpacked the rootfs, executed the
RUN, and pushed both destinations to the Gitea registry at digest a430c9c6 —
while the seven untouched kaniko steps stayed green in the same run. The
executor behaves the same and the registry auth path is unaffected, so the rest
can follow.

This moves the other seven steps here plus the one in ci-claude-refresh.yml.
Nothing but the image: lines change; no flags, no commands, no credentials.
That leaves zero gcr.io/kaniko-project references in the pipelines.

The per-step note from the first commit is gone. It described a migration state
that no longer exists, and a comment that survives its own situation is how the
velero schedule ended up claiming there was no CNPG cluster in a namespace that
had one. The durable half moved to the file header, where it explains why the
kaniko image is not Google's and why the pin is past the version their repo
ended on.

Also corrects the admission policy's comment, which cited
gcr.io/kaniko-project/executor as the image its exemption was verified against.
Worth being precise about what did not change: the policy matches on the buildx
plugin image only and never on kaniko, so the swap needed no policy edit — which
is exactly why the stale image reference in the prose was easy to miss.

Closes #552

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

review-bot reviewed

2026-08-27 11:05:44 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit 60f231f8392465d917ecbb39214c0da319c603a2.

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

Summary

Mechanical follow-up to #552: swaps the remaining eight gcr.io/kaniko-project/executor:v1.23.2-debug references (seven in build-ci-images.yml, one in ci-claude-refresh.yml) for the maintained fork registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug, moves the per-step migration commentary into a repo-durable header note, and corrects a stale gcr.io/kaniko-project mention in the admission-policy prose. Only image: lines and comments change — no flags, commands, or credentials. Verified against the checkout: no gcr.io/kaniko-project references remain anywhere in the repo, and the admission policy's privileged match is confirmed to key off woodpeckerci/plugin-docker-buildx only (kubernetes/infrastructure/admission-policies/woodpecker-ci-restrict.yaml:41-42,57-62), never the kaniko image — so the PR body's claim that no policy change was needed is accurate. No blocking issues found.

🟡 Suggestions

.woodpecker/build-ci-images.yml:9-19 — the new header comment restates rationale that's also partially in the (now-removed) old per-step comment and the PR description. Not a problem, just note that if the fork is re-pinned again later, this header is now the single place that needs updating (the #552 reference and "v1.24.0 the Google repo ended on" framing will read oddly a few pins from now) — worth a quick sanity check on the next bump rather than blindly trusting the historical framing.

Tests

No automated tests apply to this change (Woodpecker pipeline YAML + a comment-only edit in a static admission-policy manifest). The PR body documents a real-world verification instead: build-alpine-jq was run against the new fork image in a prior staged commit and pushed successfully while the other seven kaniko steps stayed on the old image and stayed green — a reasonable substitute for a test here, though it only exercises build-alpine-jq's Containerfile/context, not the other seven steps' specific build paths. Since the executor binary, flags, and directory layout are unchanged (only the tag moved), the risk of the other seven steps behaving differently is low, but the next actual CI run of this pipeline is effectively the test for the remaining steps.

Recommendation

Looks reasonable — no blocking issues; comment above is optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `60f231f8392465d917ecbb39214c0da319c603a2`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Mechanical follow-up to #552: swaps the remaining eight `gcr.io/kaniko-project/executor:v1.23.2-debug` references (seven in `build-ci-images.yml`, one in `ci-claude-refresh.yml`) for the maintained fork `registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug`, moves the per-step migration commentary into a repo-durable header note, and corrects a stale `gcr.io/kaniko-project` mention in the admission-policy prose. Only `image:` lines and comments change — no flags, commands, or credentials. Verified against the checkout: no `gcr.io/kaniko-project` references remain anywhere in the repo, and the admission policy's `privileged` match is confirmed to key off `woodpeckerci/plugin-docker-buildx` only (`kubernetes/infrastructure/admission-policies/woodpecker-ci-restrict.yaml:41-42,57-62`), never the kaniko image — so the PR body's claim that no policy change was needed is accurate. No blocking issues found. ## 🟡 Suggestions - `.woodpecker/build-ci-images.yml:9-19` — the new header comment restates rationale that's also partially in the (now-removed) old per-step comment and the PR description. Not a problem, just note that if the fork is re-pinned again later, this header is now the single place that needs updating (the `#552` reference and "v1.24.0 the Google repo ended on" framing will read oddly a few pins from now) — worth a quick sanity check on the next bump rather than blindly trusting the historical framing. ## Tests No automated tests apply to this change (Woodpecker pipeline YAML + a comment-only edit in a static admission-policy manifest). The PR body documents a real-world verification instead: `build-alpine-jq` was run against the new fork image in a prior staged commit and pushed successfully while the other seven kaniko steps stayed on the old image and stayed green — a reasonable substitute for a test here, though it only exercises `build-alpine-jq`'s Containerfile/context, not the other seven steps' specific build paths. Since the executor binary, flags, and directory layout are unchanged (only the tag moved), the risk of the other seven steps behaving differently is low, but the next actual CI run of this pipeline is effectively the test for the remaining steps. ## Recommendation Looks reasonable — no blocking issues; comment above is optional.

k.renner merged commit 2549535961 into master

2026-08-27 11:11:23 +00:00

k.renner referenced this issue from a commit

2026-08-27 11:11:24 +00:00

Merge pull request 'ci(kaniko): move the remaining eight builds to the maintained fork' (#665) from kaniko-fork-rest into master

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#665