ci: validate the GitOps tree and pipeline configs on every PR #460
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: konairius/homelab#460
Reference in New Issue
Block a user
Closes the gap reviewers flagged on three separate PRs today: nothing validates
kubernetes/**.deploy-infrastructure.ymlgates onlyopentofu/**, andci-scripts-test.ymlruns only thescripts/ci/unit tests — so a broken manifest reached the cluster and was caught by Flux failing to reconcile, or by someone noticing.Four checks, all offline
No cluster, no registry, no secrets — every one passes or fails on the checkout alone.
kustomize-buildwoodpecker-lintshellcheck.shunderkubernetes/, severityerrorno-digest-pins@sha256pinsEach was verified green against the tree as it stands before being added, so this gates new breakage rather than failing on pre-existing debt: all 60 kustomizations build, all pipeline configs lint, all 6 shell scripts are clean at error severity, and no digest pins remain after #459.
The lint step is the one that matters
It exits 1 on the exact defect that took every pipeline in this repo down earlier today (#443) — an unquoted YAML scalar containing
": ", whichyqaccepts because it is valid YAML, just a map instead of a string. That's why "it parses" was mistaken for "it's valid".Verified both directions in the image the step actually uses:
and
rc=0on the pre-existingAdditional property timeout is not allowedwarnings in fourdeploy-*.ymlfiles — so it fails on real breakage without blocking on legacy noise.Image choices — all version-pinned, no floating tags
ci-k8s:2026-07-30—kubectlfor kustomize, and the shell for the grep guard. (I first wrote:latesthere; caught and fixed, per the never-latestrule.)woodpecker-cli:v3.16.0-alpine— the non-alpine image is scratch-based with no/bin/sh(19 MB, 2 layers), so Woodpeckercommands:cannot run in it at all. The binary is/bin/woodpecker-cli, not onPATHaswoodpecker. Both found by probing the image rather than assuming.shellcheck-alpine:v0.11.0— pinned rather than:stable, which floats exactly like:latest.Deliberately not included
kubeconform. It needs CRD schemas forExternalSecret,Certificate,HelmReleaseand friends — so it either needs a schema-fetching step (network access, and a new flake source) or-ignore-missing-schemas, which would skip precisely the CRDs most of this tree is made of. Worth doing properly as its own change rather than adding a check that looks like coverage and isn't.Known gap, stated rather than implied away
shellcheckcannot see shell embedded in manifests — init containers, probeexecblocks. That's where several real bugs lived this year (thegrep --line-bufferedno-op, themosquitto_pub -Wflag that doesn't exist). Called out in the file so nobody reads this pipeline as covering it.🤖 Generated with Claude Code
🤖 Automated review — model
claude-sonnet-5(complexity: normal), commitcd12bc16c9b2bf78b02b95ba97870a1184ab371a.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new offline pull_request pipeline with four steps (kustomize-build,woodpecker-lint,shellcheck,no-digest-pins) closing a real gap: nothing currently validateskubernetes/**. The rationale is well-documented, the claimed facts about the current tree (60 kustomizations, 6 shell scripts, 4deploy-*.ymlfiles with the pre-existingtimeoutwarning, no digest pins remaining underopenbao/rotation/) all check out against the checkout. One likely portability bug in the flagshipkustomize-buildstep needs to be settled before merge — see below.🔴 Blocking
.woodpecker/ci-manifests-test.yml:36—find kubernetes -name kustomization.yaml -printf '%h\n'relies on-printf, a GNU findutils extension. Thekustomize-buildstep runs ingitea.renner.uno/gitea_admin/ci-k8s:2026-07-30, whoseContainerfile(ci/images/k8s/Containerfile) isFROM alpine:3.21and onlyapk addsaws-cli bash bind-tools ca-certificates curl git openssh-client openssl sops— it never installsfindutilsorcoreutils. That meansfindresolves to BusyBox'sfindapplet, which historically does not implement-printf(its documented action set is-print/-print0/-prune/-delete/-exec/… but no-printf).If that holds, the failure mode is not a loud error — it's silent:
for d in $(find … -printf …)sits inside a command substitution used as a word list, so underset -eua failing/erroringfindjust yields empty stdout, theforloop runs zero times,failstays0, and the step exits0. The step would report green on every PR without ever runningkubectl kustomizeon anything, which is the opposite of what this PR is for.I could not execute the actual container image from this environment to confirm BusyBox's exact feature set in this build, so I'm not stating this as certain — but it's a specific, checkable claim. The one check that settles it:
docker run --rm gitea.renner.uno/gitea_admin/ci-k8s:2026-07-30 sh -c "find --help 2>&1 | grep printf"(or just run the step's loop by hand once). If-printfisn't supported, a portable fix is-exec dirname {} \;in place of-printf '%h\n', which BusyBox'sfinddoes document.🟡 Suggestions
woodpecker-lint,shellcheck,no-digest-pins) uses only basicfind -name/glob/grep constructs that are portable across BusyBox and GNU implementations, and the claims in the PR body about the current state of the tree (60 kustomizations, 6.shfiles underkubernetes/, no@sha256pins underopenbao/rotation/,timeout:present in exactly the four nameddeploy-*.ymlfiles) all verified against the checkout.🟢 Nits
None.
Tests
This is the test/validation infrastructure — there's no meta-test for a CI pipeline definition beyond what the PR description already reports (each step run against the current tree, both directions verified for
woodpecker-lint). That's a reasonable bar for this kind of change. The one gap is the-printfportability question above, which by nature wouldn't be caught by "run it against a healthy tree and see green" — a silently-no-op step and a correctly-working step produce the same observable result (exit 0) when every kustomization already builds cleanly, which is exactly the situation described in the PR body ("all 60 kustomizations build"). Worth having the author paste the actualkustomize-buildstep log (with per-directoryok/FAILlines, not just the final exit code) to prove the loop iterated 60 times rather than zero.Recommendation
Request changes — 1 blocking issue (unverified but concrete: confirm
find -printfworks in theci-k8s:2026-07-30image, or switch to-exec dirname {} \;).🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit790fd1933a4c45ecd49cdf31a91c8e4da2072a4b.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new pull_request-triggered pipeline with four offline, static checks overkubernetes/**and.woodpecker/**:kustomize-build,woodpecker-lint,shellcheck, andno-digest-pins. I re-derived every quantitative claim in the PR body against the checkout (kustomization count, shell-script count, current digest-pin state, the self-match/exclusion behavior of theno-digest-pinsgrep) and all of them check out. No blocking issues.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:140-141— the comment "image:anchors the match so the kustomization comment documenting this rule does not flag itself" is inaccurate about the mechanism. I ran the actual grep (grep -l 'image:.*@sha256' kubernetes/infrastructure/openbao/rotation/*.yaml) against the checkout:kustomization.yamldoes match — its own documentation comment atkubernetes/infrastructure/openbao/rotation/kustomization.yaml:33-34literally contains the substringimage:.*@sha256, which satisfies the regex. What actually excludes it is the subsequentgrep -v kustomization.yamlfilename filter, not "image:anchoring." The behavior is correct (confirmed: the pipe correctly drops it,no-digest-pinswould pass today), andkubernetes/infrastructure/openbao/rotation/kustomization.yaml:36-39already documents this self-match/filter interaction accurately — only the new file's comment mischaracterizes it. Worth a one-line fix since this codebase clearly leans on comments being trustworthy documentation of trap behavior..woodpecker/ci-manifests-test.yml:37,143—ci-k8s:2026-07-30and (line 81)woodpecker-cli:v3.9.0-alpine/ (line 107)shellcheck-alpine:v0.10.0are the first references to these tags/images anywhere in the repo (existing pipelines pinci-k8s:2026-05-01). I can't pull images from this sandbox to confirmci-k8s:2026-07-30has actually been pushed to the registry — if it hasn't, bothkustomize-buildandno-digest-pinsfail at image-pull on every PR rather than at the check itself. Circumstantial evidence is good (other rotator manifests already referencesecret-rotator:2026-07-30, built by the same date-tagging convention inbuild-ci-images.yml, and today's date is 2026-07-30), but this is worth a final confirmation that the tag resolves before merge, since a pull failure here would block every PR, not just ones touchingkubernetes/**.Tests
Not applicable in the traditional sense — this PR is the test harness for
kubernetes/**and.woodpecker/**. The right validation is running each check against the real checkout/images, which the PR body describes doing and which I independently reproduced for the parts checkable from disk:find kubernetes -name kustomization.yaml→ 60 (guard threshold 50, comfortable margin),find kubernetes -name '*.sh'→ 6 scripts, all with proper shebangs (bashorsh) soshellcheckcan auto-detect dialect without a-sflag, and no@sha256-pinned images currently underopenbao/rotation/. Thewoodpecker-lintand image-pull correctness claims (verified against the live images per the PR body) aren't independently checkable from this sandboxed, network-isolated checkout.Recommendation
Looks reasonable — no blocking issues; comments above are optional.
Blocking issue confirmed and fixed in
790fd193. You were right, and the diagnosis was exact.The gate was a silent no-op
Confirmed by running it in the image rather than reasoning about BusyBox feature sets:
And the proof it mattered is in this PR's own pipeline run 3158: the
kustomize-buildstep is recorded as success, and its log contains zerooklines where sixty were expected. So the gate I wrote to catch silent no-ops was itself one, and CI reported it green.Why my verification missed it, twice
Worth recording, because both failures were confident:
-printfworks.Your suggested check (inspect the per-directory log lines, not the exit code) is the only one that separates those cases. I had the log available and did not look at it.
Fixed, and verified the way you asked
Portable discovery via
find … | sed 's|/kustomization.yaml$||'. Pipeline run 3161:Same
successstatus as before, sixty times the actual work.The general fix, which matters more than the -printf detail
Both find-based steps now assert their discovery found something before proceeding —
kustomize-buildrequires >=50 of the ~60,shellcheckrequires >=1 — and fail loudly otherwise.Without that, any future breakage of discovery degrades back into a green no-op.
-printfwas the symptom; a check that cannot tell it checked nothing is the disease, and it is the same shape as the two bugs this pipeline was written to catch (grep --line-bufferedsilently matching nothing,mosquitto_pub -Wsilently failing every publish).Both addressed.
🟡 The comment misidentified the mechanism — you are right
Verified by running the bare grep exactly as you did:
So
image:anchoring does nothing for self-matching; the filename filter is load-bearing. Fixed, and the comment now says so explicitly — because a comment that misidentifies the load-bearing line invites someone to delete the filter as redundant tidying, at which point the step fails permanently on its own documentation.Worth admitting this is the third time today the same self-matching trap caught me: twice while writing the guard in
rotation/kustomization.yaml, and once more in the comment describing it here. You are also right that this codebase leans on comments being trustworthy — a wrong explanation next to correct code is its own defect.🟡 Confirming the image tags resolve
Good instinct, and the consequence you name is right: this pipeline has no path filter, so it runs on every PR — an unpullable image would block all of them, not just
kubernetes/**ones.Stronger evidence than a manual pull: pipeline 3161 ran this pipeline against a real checkout and every step succeeded, which means all three images pulled in the runner:
And
discovered 60 kustomizations/ 60oklines in that same run, so it pulled and did the work.On
ci-k8s:2026-05-01being what other pipelines pin: that is worth a separate look.ci-k8sis rebuilt whenever.woodpecker/build-ci-images.ymlchanges, so newer dated tags exist and the older pin is simply stale rather than deliberate — the same drift that left the rotators pinned to dead digests, just less severe because a tag does not get garbage-collected.🤖 Automated review — model
claude-sonnet-5(complexity: normal), commitddf5f5007bad978c797f1e3cf75fc0468daa0142.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new offlinepull_requestpipeline with four steps (kustomize-build,woodpecker-lint,shellcheck,no-digest-pins) that closes a real, previously-demonstrated gap: nothing validatedkubernetes/**or the pipeline configs themselves before this. I checked the script logic line by line against the actual checkout and it holds up — counts match (60 kustomizations, 6 shell scripts underkubernetes/), theno-digest-pinsgrep-filter self-match claim is verified againstkubernetes/infrastructure/openbao/rotation/kustomization.yaml, and theerrexit/if-exemption reasoning in the comments is correct POSIX sh behavior. No secrets, no cluster/network access, no blocking defects found.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:31,143— new image taggitea.renner.uno/gitea_admin/ci-k8s:2026-07-30cannot be verified from this checkout (no network/registry access here). This repo has already been bitten by exactly this failure mode once:kubernetes/infrastructure/openbao/rotation/kustomization.yamldocuments 11 rotators that silently died because they were pinned to a manifest that no longer resolved (#458), and its own "BUMPING the tag" guidance says to verify a new tag exists before committing, since an unbuilt tag fails "just as quietly." Every other pipeline in.woodpecker/that uses this image referencesci-k8s:2026-05-01(e.g.e2e.yml,alert-monitor.yml,issue-fix.yml) — this PR is the first reference to the2026-07-30tag anywhere in the tree, and the diff doesn't touchci/images/k8s/**, so nothing in this PR itself triggers a rebuild that would publish it. If that tag wasn't pushed by a separatebuild-ci-imagesrun today, both steps that use it will fail to pull the image on every PR. Low risk of silent failure (a bad pull fails loudly), but worth confirming the tag resolves — the first CI run of this very pipeline will prove it either way.path:filter on thewhen:block (ci-manifests-test.yml:25-26), so all four steps run on every PR regardless of whetherkubernetes/**or.woodpecker/**changed (e.g. a docs-only PR still pulls three extra images and builds 60 kustomizations). This matches the existing convention inci-scripts-test.yml(also unfiltered), so it's consistent with the repo's style rather than a new problem — just flagging in case unfiltered-by-design wasn't the intent here too.$dirs/$filesin theforloops (kustomize-build,shellchecksteps) would break on a directory or filename containing whitespace. Not an issue for the current tree (checked — no such names underkubernetes/), and consistent with the informal quoting style elsewhere in.woodpecker/*.yml, so this is a latent assumption rather than a live bug.Tests
This is itself the test: a CI-validation pipeline whose correctness is demonstrated by running against the real tree, which happens automatically on this PR. The anti-no-op guards (
count -lt 50/count -lt 1thresholds inkustomize-buildandshellcheck) are a genuinely good touch — they specifically prevent the failure mode the PR body describes happening once already (discovery silently returning nothing, step reporting green). No separate unit-test file is expected or missing here, matching howci-scripts-test.yml/deploy-infrastructure.ymlaren't unit-tested either.Recommendation
Looks reasonable — no blocking issues; comments above (mainly: confirm the
ci-k8s:2026-07-30tag resolves) are optional and self-resolving on the first CI run.The previous commit set IFS to a literal newline by writing IFS=" " inside a `- |` block scalar. The closing quote sits at column 0, which terminates the block — so the config no longer parsed: go-yaml load error in scanner (while scanning a simple key) at L70.C1-L89.C3: could not find expected ':' Same class as #443, in the very pipeline written to catch #443, and I pushed it: `woodpecker lint` printed the error in the same command as the push, and I read the push output rather than the lint output. Replaced with `while IFS= read -r` fed from a FILE rather than a pipe. That handles paths with spaces without needing a literal newline anywhere, and the file redirection keeps the loop in the current shell so `fail` still propagates — a pipe would have run it in a subshell and made a failing kustomize build exit 0, which is the silent-pass shape this step already shipped once with -printf. Verified both properties in the actual image rather than reasoning about them: a directory named "has space" iterates once intact, and a `fail=1` set inside the loop is still 1 after it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit9d3dc152c1b03afe6d810673664b64ea5886b764.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new pull-request-gated pipeline with four offline checks:kubectl kustomizebuild for every kustomization,woodpecker-cli linton all pipeline configs,shellcheckon standalone scripts underkubernetes/, and a grep guard against digest-pinned images in the secret-rotator manifests. I cross-checked the concrete claims in the PR body and inline comments against the actual tree rather than taking them on faith:find kubernetes -name kustomization.yaml | wc -lreturns exactly 60,find kubernetes -name '*.sh'returns exactly the 6 scripts implied, and the "thegrep -v kustomization.yamlfilter is load-bearing" claim checks out —kubernetes/infrastructure/openbao/rotation/kustomization.yamlreally does contain the literal stringimage:.*@sha256in its own explanatory comment, so without the filter this step would permanently fail on its own documentation. The shell in every step is careful about the exact class of bug it's guarding against (pipedfind/sedswallowing failures underset -e,while readfrom a pipe losingfailin a subshell, silent-empty-discovery reporting green) — I traced through theset -euinteraction withif/pipeline exit-status semantics for each step and didn't find a case where a real failure gets swallowed. No blocking defects found in the logic itself.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:40and:162— bothkustomize-buildandno-digest-pinspin togitea.renner.uno/gitea_admin/ci-k8s:2026-07-30, today's date. That tag only exists ifbuild-ci-images.yml'sbuild-k8sstep has already run successfully today — and that step only fires on changes toci/images/k8s/**or.woodpecker/build-ci-images.yml(or a manual trigger), none of which this PR touches. Contrast withdeploy-infrastructure.yml, which pinsci-tofu:2026-04-29— a tag from three months ago, long since confirmed to exist. I don't have registry access from this review sandbox to confirmci-k8s:2026-07-30was actually pushed; if it wasn't, both steps fail immediately on an image pull error, which would be a somewhat ironic first impression for a PR about catching CI breakage before merge. Worth confirming the tag is live (check today'sbuild-ci-imagesrun history) before relying on this passing, or falling back to the last known-goodci-k8stag if not..woodpecker/ci-manifests-test.yml:39-173— none of the four steps setfailure: ignore, and Woodpecker runs steps sequentially by default (nodepends_onhere). Ifkustomize-buildfails,woodpecker-lint,shellcheck, andno-digest-pinsnever execute, so a contributor sees only the first failing check per push and has to fix-and-repush to discover the next one. Since all four are independent, cheap, offline checks, running them to completion (viafailure: ignoreon each, or splitting into adepends_on: []fan-out likebuild-ci-images.ymldoes) would surface every failure in one run.🟢 Nits
.woodpecker/ci-manifests-test.yml:58— thecount -lt 50floor for "expected ~60 kustomizations" is a reasonable trip-wire today, but it's a hardcoded number with no pointer to update it; if a future legitimate consolidation drops the real count into the 50s this fails for the wrong reason. Not urgent given the current margin.Tests
This PR is a test/validation pipeline, so there's no separate test suite to ask for — the equivalent here is the manual verification the author describes (both branches of the lint-catches-#443 bug exercised, false-positive/false-negative behavior on existing warnings checked) plus the sanity checks I independently reran above (kustomization count, script count, the load-bearing grep filter). Those all check out against the current tree.
Recommendation
Looks reasonable — no blocking issues; the image-tag freshness point above is worth confirming before merge but isn't a confirmed defect.
🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit888aa60fe048bf8eb5f7a3cc6c1b099296906a54.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new PR-triggered pipeline with four parallel, offline checks overkubernetes/**and.woodpecker/**:kustomize-build(all kustomizations build),woodpecker-lint(pipeline configs compile),shellcheck(standalone scripts underkubernetes/), andno-digest-pins(guards the dated-tag convention in the openbao rotation dir). This is a pure CI-config addition (single new file, no other code touched). I checked every factual claim in the PR body and every non-trivial shell construct against the actual checkout — the counts (60 kustomizations, 6 shell scripts), the self-matchinggreppattern inrotation/kustomization.yaml, the absence of remote bases/helmCharts(confirming the kustomize step really is offline), and the busybox-find-lacks--printfclaim (confirmed: theci-k8sContainerfile'sapk addlist has nofindutils) all check out. I found no blocking defects.🟡 Suggestions
woodpecker-lintstep uses a CLI version well behind the deployed server (.woodpecker/ci-manifests-test.yml:103useswoodpeckerci/woodpecker-cli:v3.9.0-alpine, butkubernetes/apps/woodpecker/server.yaml:43andagent.yaml:37runv3.16.0). The PR body itself noteswoodpecker-cli lintcurrently emitsAdditional property timeout is not allowedwarnings on severaldeploy-*.ymlfiles and treats those as harmless pre-existing noise — but that symptom is also consistent with schema drift between a 7-minor-version-old lint tool and the actual v3.16.0 schema those files were written against, rather than genuine debt. A large version gap risks the reverse case too: syntax the real v3.16.0 server accepts could someday be flagged as a compile error by the old CLI (false-fail), or syntax it should reject could pass (false-pass). Consider pinning the lint image to (or near)v3.16.0for higher-fidelity linting.kustomize-builduseskubectl kustomize, notflux build, even though the sameci-k8simage already shipsflux(ci/images/k8s/Containerfile) — so it doesn't exercise Flux'spostBuild.substitutestep used bykubernetes/clusters/homelab/infrastructure.yaml. A manifest can pass this new check (kustomize builds cleanly, since${VAR}-style substitution placeholders are just inert text to kustomize) yet still fail at Flux reconcile time if the substitution step itself breaks. This doesn't need to block the PR, but given the file is explicit elsewhere about stating known gaps rather than implying coverage it doesn't have (the shellcheck-can't-see-embedded-shell note at.woodpecker/ci-manifests-test.yml:124-127), the same treatment here would be consistent — either a one-line callout, or switching toflux build kustomizationfor closer fidelity to production reconciliation.Tests
N/A — this PR is the test/validation infrastructure; there's nothing further to test it with. The author's verification methodology (running both steps against real repo content and a known-bad historical config, described in the PR body) is a reasonable substitute for automated tests on a CI-config file, and the specific claims I could check independently (kustomization/script counts, the self-matching grep, the offline-only property) all held up.
Recommendation
Looks reasonable — no blocking issues; comments above are optional.
🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit7b5f244b7f44e7d1749d7a8168007fbc3e57c5b9.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new pull-request pipeline with four parallel, offline checks overkubernetes/**and.woodpecker/**:kubectl kustomizebuild of every kustomization,woodpecker-cli lintof every pipeline file,shellcheck -S erroron standalone shell scripts, and a grep guard against digest-pinned images in the secret-rotator directory. I independently re-verified the PR's factual claims against the checkout (60 kustomizations, 6 shell scripts, zero digest pins outside the self-documenting comment, and the woodpecker-cli version matching the deployed server) and they all hold. The shell logic in each step is careful and correct — no blocking issues found.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:62(kustomize-build) and:150(shellcheck): neither step setsset -o pipefail(and BusyBox/ash/dash don't support it anyway), sodirs=$(find kubernetes -name kustomization.yaml | sed ... | sort)takes its exit status fromsort, notfind. Afindfailure on a subtree (e.g. a permission error) that still letssed/sortexit 0 would silently drop entries from the list rather than failing the step. Thecount -lt 50floor catches total discovery breakage (the documented "empty output" bug) but not a partial loss of a few directories. Given the floor already exists and this is a low-likelihood failure mode in a repo you fully control, this is a nit-level robustness gap, not a blocker.woodpecker-lintstep (:109-129) is the one the PR body calls "the one that matters," and its correctness hinges on/bin/woodpecker-clibeing the right binary path and the-alpineimage actually containing/bin/shfor thecommands:block to run at all. I don't have registry/image-pull access in this sandbox to independently confirm that againstwoodpeckerci/woodpecker-cli:v3.16.0-alpine, so I'm relying on the PR body's claim of having probed the image directly. Worth a final sanity check that this step actually goes green in CI on this PR (rather than failing to even start the container) before merging, since a wrong binary path fails closed in a way that's easy to misattribute to a bug in the pipeline being linted.🟢 Nits
woodpecker-cli:v3.9.0-alpineandshellcheck-alpine:v0.10.0, while the actual file (after the follow-up "use latest stable versions" commit) pinsv3.16.0-alpineandv0.11.0. Not a code issue, just worth updating the description before merge so reviewers reading the body aren't checking against the wrong tags.Tests
This is a CI-config-only change, so there's no unit test to add in the usual sense — the pipeline's own
woodpecker-lintstep and the manual dry-runs described in the PR body (rc=0 on valid config, rc=1 reproducing the #443 bug) are the applicable verification, and that's consistent with how other pipeline-definition files in this repo (e.g.build-ci-images.yml) are validated. I re-ran the factual checks that the PR body claims (kustomization count, shell script count, digest-pin grep, server version) directly against the checkout and all matched.Recommendation
Looks reasonable — no blocking issues; comments above are optional.
🤖 Automated review — model
claude-sonnet-5(complexity: normal), commitfbfaf90923251aeed6b2b2ae400daac6210472da.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new pull-request pipeline with four independent, offline, secret-free checks:kustomize-build(all kustomizations underkubernetes/build),woodpecker-lint(all.woodpecker/*.ymlcompile),shellcheck(standalone scripts underkubernetes/, severityerror), andno-digest-pins(guards against digest-pinned rotator images). I checked every concrete claim in the PR body against the checkout — file counts, thebusybox findlimitation, theimage:.*@sha256self-match inrotation/kustomization.yaml, the deployedwoodpecker-serverversion, and the absence of remote kustomize bases — and all of them hold. No blocking issues found.🟡 Suggestions
woodpecker-cli:v3.9.0-alpine, but.woodpecker/ci-manifests-test.yml:118pinswoodpeckerci/woodpecker-cli:v3.16.0-alpine(which does correctly match the deployedwoodpecker-server:v3.16.0inkubernetes/apps/woodpecker/server.yaml:43, per the comment's stated rationale). The code is right; the PR body just wasn't updated after a later revision — worth a quick edit so future readers of the PR history aren't misled about which tag was actually shipped.ci-k8s:2026-07-30(line 51/205),woodpecker-cli:v3.16.0-alpine(line 124), andshellcheck-alpine:v0.11.0(line 155) all need to actually resolve in their registries for this pipeline to run at all; I have no registry/network access here to confirm. The PR body says these were probed directly, which I have no reason to doubt given how well the rest of the PR's claims checked out against the tree — just flagging that this is the one category of claim I couldn't independently verify.🟢 Nits
depends_on: []rationale comment (lines 46-49, 119-122, 150-153, 200-203) is duplicated verbatim across all four steps. Not wrong, just repetitive — could live once at the top ofsteps:if it's ever edited.Tests
This is CI infrastructure, not application code, so there's no unit-test layer to add — the "test" is the pipeline itself running green against the current tree, which the PR body says was done for each step. The design already builds in its own regression guard: both
kustomize-buildandshellcheckassert a minimum discovered-file count (kubernetes/ci-manifests-test.yml:69,:163) specifically so a brokenfind/sedpipeline fails loudly instead of silently passing with zero iterations — a real failure mode the PR body says bit the first draft of this file. That's a solid substitute for tests in a context where "tests" would just be "run the thing."Recommendation
Looks reasonable — no blocking issues; comments above are optional.
🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit8a580e341d61b194858584a484792cd5a5cc02af.Summary
Adds
.woodpecker/ci-manifests-test.yml, a newpull_requestpipeline with four offline, parallel steps (kustomize-build,woodpecker-lint,shellcheck,no-digest-pins) gatingkubernetes/**and.woodpecker/**, plus doc updates recording thatwoodpeckerci/woodpecker-clican't be enrolled in image-automation. The shell logic is careful (file-fedwhile read, discovery-count floors, quoting) and most of the PR body's factual claims check out against the checkout (60 kustomizations, 6 shell scripts, zero digest pins underopenbao/rotation/,v3.16.0matching the deployed server, exactly 4deploy-*.ymlfiles with thetimeoutproperty). No blocking issues confirmed, but one risk below is significant enough to verify before merge.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:51,218— unverified image tag, and the evidence available points the wrong way. Bothkustomize-buildandno-digest-pinspingitea.renner.uno/gitea_admin/ci-k8s:2026-07-30. Every other pipeline file in the repo (alert-monitor.yml:45,e2e.yml:33,e2e-test.yml:7,issue-fix.yml:52) still pinsci-k8s:2026-05-01. Per.woodpecker/build-ci-images.yml:55-62, thebuild-k8sstep only runs (and only mints a new dated tag) whenci/images/k8s/**orbuild-ci-images.ymlitself changes on a push — and this PR's diff touches neither. The one piece of same-day evidence,secret-rotator:2026-07-30(visible throughoutkubernetes/infrastructure/openbao/rotation/*.yaml), doesn't transfer: that image is built by an independent step (build-secret-rotator, gated onsecret-rotator/**), so its rebuild today (for #458) says nothing about whetherbuild-k8salso ran today. Ifci-k8s:2026-07-30was never pushed,kustomize-buildandno-digest-pinsfail immediately on image pull for every future PR touchingkubernetes/**or.woodpecker/**.I can't confirm this from the checkout (no registry/network access here), so I'm not marking it blocking — but there's a check that settles it directly: this PR's own diff touches
.woodpecker/ci-manifests-test.ymlandkubernetes/infrastructure/image-automation/README.md, both matching the new pipeline's own path filter, so its own CI run already attempted these two steps. Check that build's logs/status before merging.PR description drifted from the shipped versions. The description states verification was done against
woodpecker-cli:v3.9.0-alpineandshellcheck-alpine:v0.10.0, but the diff shipsv3.16.0-alpine(ci-manifests-test.yml:131) andv0.11.0(ci-manifests-test.yml:168). The specific empirical claims in the body ("verified both directions... in the image the step actually uses", the no-/bin/shprobing) were run against different tags than what's actually in the pipeline. Probably fine (both are point-bumps within the same alpine variant), but worth a quick re-check thatv3.16.0-alpinestill ships/bin/shand thatlintbehavior is unchanged, since the description's evidence no longer matches the code as diffed.🟢 Nits
.woodpecker/ci-manifests-test.yml:137—woodpecker-cli lint "$f"lints one file at a time in a loop; this matches the documented CLI usage as far as I can tell, but I couldn't execute it in this sandbox (no container runtime/network available) to confirm the single-file invocation and exit-code behavior first-hand.Tests
N/A in the traditional sense — this PR is the test/gate. Its own effectiveness is empirically argued in the description (verified against the #443 regression and the current tree state), and the numeric claims I could check against the checkout (kustomization count, script count, absence of digest pins, server/CLI version match) all held up. The main untested-in-this-review path is the actual CI run of the new pipeline itself (see the image-tag point above).
Recommendation
Looks reasonable — no confirmed blocking issues; the
ci-k8s:2026-07-30tag risk above is worth confirming against this PR's own CI run before merging.Both 🟡 points and the nit are addressed in
51153788.1.
ci-k8s:2026-07-30may never have been built — good catch on the mechanism:build-k8sonly mints a dated tag whenci/images/k8s/**orbuild-ci-images.ymlchanges on a push, this PR touches neither, and you were right thatsecret-rotator:2026-07-30doesn't transfer (separately-gated step). I checked rather than assumed. The registry API is closed to this token (read:packagenot granted), so the evidence is the run you pointed at: pipeline 3178 on8a580e34—kustomize-buildandno-digest-pinsboth green on that exact tag, with 60 realoklines. An unpullable image cannot produce that. Tag exists; no change needed.2.
v3.16.0-alpineunverified — same run:woodpecker-lintemitted 18oklines, one per.woodpecker/*.yml, which is only reachable if the image has a working/bin/shand/bin/woodpecker-cli. So the single-file invocation and exit-code behaviour are confirmed against the shipped tag.But this one exposed something I could not verify, and your earlier hypothesis was the reason I looked. The comment asserted that several
deploy-*.ymlfiles emitAdditional property timeout is not allowed. That was observed under v3.9.0, the tag this step used to pin. Whether v3.16.0 still emits it is unknown — and a green run cannot settle it, because the loop sends lint output to/tmp/outand prints it only on failure, so warnings are invisible precisely when the step passes. Your read (schema drift in a 7-minor-old CLI rather than real debt in those files) is plausible and untested. I dropped the claim rather than restating it; the comment now documents only the exit-code contract the gate actually rests on.3. Nit — duplicated
depends_onrationale — hoisted to a single note abovesteps:, with a warning that the key itself must stay on every step (it's per-step; removing it from one silently re-serialises that step).PR description — updated. You were right that the body still quoted
v3.9.0-alpine/v0.10.0as shipped, so the probing evidence referred to different tags than the diff. Corrected in place with an explicit note recording the bump rather than quietly rewriting it.Also worth recording, since it's the substantive change in
8a580e34and it went the opposite way from what I proposed: I had intended to enrollwoodpecker-cliin image-automation so the pin would stop being manual, by wideningupdate.pathto./. That cannot work. Image-automation only patches YAML that is a Kubernetes manifest — fluxcd/flux2#2826: "Flux can only patch Kubernetes manifests. This means the YAML manifest must haveapiVersionandkindfields." A Woodpecker pipeline file has neither, so a marker here is silently ignored. That's a property of the file, not ofupdate.path, so widening buys nothing and would drag 197 unrelated ansible/esphome YAMLs into the walk. The pin stays manual by necessity; drift is now covered by the update-audit agent, which is told to flag this image whenever it trails the deployed server.🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit51153788358ed862125c75521709622a61b90660.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new PR-gated pipeline with four offline, parallel checks (kustomize-build,woodpecker-lint,shellcheck,no-digest-pins), plus documentation updates inci/agents/update-audit/prompt.mdandkubernetes/infrastructure/image-automation/README.mdexplaining why thewoodpecker-cliimage pin can't be enrolled in image-automation. This is round 2 (commit5115378already addressed a prior review's two 🟡 points and one nit). I verified the concrete claims against the checkout — kustomization count (60), shell script count (6), theno-digest-pinsgrep behavior against the actual rotation directory, thekubectl/find/sed toolchain in theci-k8simage's Containerfile, the.woodpeckerfile count (18), and that none of the 60 kustomizations reference remote bases (so the "offline" claim holds). Everything checks out; no blocking issues.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:52-97(kustomize-build) and:170-198(shellcheck) each hand-roll the same "discover withfind, guard against empty discovery, feed a file intowhile read" pattern. Not asking for an extraction — two instances doesn't justify one, and the file-vs-pipe subshell reasoning is genuinely two different traps worth spelling out locally — but if a third check with the same shape gets added later, that's the point to factor it into a shared step or script underscripts/ci/..woodpecker/ci-manifests-test.yml:136claims wideningupdate.pathwould "drag 197 unrelated ansible/esphome YAMLs into the walk." I counted 180.yml/.yamlfiles directly underansible/+esphome/in this checkout — in the right ballpark and the underlying argument (widening the path pulls in a lot of unrelated files) holds regardless, but the specific figure doesn't reproduce exactly from what's countable here. Worth a quick re-check of however "197" was originally derived (e.g. did it include other top-level YAML too) before treating it as load-bearing precision elsewhere.Tests
This PR is the test infrastructure — there's no meaningful separate test to add. The pipeline's own correctness was validated by an actual CI run referenced in the round-2 commit message (pipeline 3178 on
8a580e34:kustomize-buildandno-digest-pinsgreen againstci-k8s:2026-07-30,woodpecker-lintemitting 18oklines underv3.16.0-alpine), which is reasonable evidence for image/tag availability that isn't independently checkable from this static checkout alone. The failure-mode self-checks built into two of the four steps (thecount -lt 50/count -lt 1guards against silent no-op discovery) are themselves a good defense against the exact regression the PR's own commit history shows this pipeline suffered once already.Recommendation
Looks reasonable — no blocking issues; comments above are optional.
Both points addressed in
13798134.The "197" figure — you're right, and it was wrong twice over. Recounted here:
ansible/has 179,esphome/has 1 → 180, matching your count exactly.Where 197 came from: I folded
.woodpecker/into the total. That's wrong on both counts — those files are neither ansible nor esphome, and they're precisely the directory you'd want in the walk, so counting them as "unrelated" inverts the argument the sentence is making. The composite is also 198, not 197, today: the original count ran againstmaster, where.woodpecker/still had 17 files becauseci-manifests-test.ymldidn't exist yet.Fixed in both places that cite it (
ci-manifests-test.ymland the image-automation README), now with the derivation shown (179 + 1) so it's re-checkable rather than a bare number. The conclusion is unaffected — wideningupdate.pathis pointless because Flux can't patch non-Kubernetes YAML at all, and the file count was only ever the secondary reason — but you were right to flag load-bearing precision that doesn't reproduce.Duplicated discovery pattern — agreed, and no extraction now. I recorded your rule-of-three where the next person will hit it: a note above
steps:saying two copies is deliberate (the two traps being commented around — BusyBoxfindlacking-printf, and a piped loop running in a subshell wherefailcan't propagate — are genuinely different and worth spelling out locally), and that a third instance is the signal to factor it intoscripts/ci/. Worth adding: anything moved there picks up unit tests viaci-scripts-test.yml, which a shell block inlined in a pipeline file can never have — so the third-instance threshold buys more than deduplication.The file count was meaningless and would be wrong tomorrow. Correcting it from 197 to 180 last commit was the wrong fix: a number that has to be re-derived every time the tree changes does not belong in a comment at all. It cost two review rounds — one to flag that 197 did not reproduce, one to correct it — and neither round was about anything that mattered, because the count was never the argument. Widening update.path is pointless because Flux cannot patch non-Kubernetes YAML at all; the size of the walk was only ever a secondary aside. Swept every snapshot figure I had introduced, not just the one flagged: * "180 unrelated ansible/esphome YAMLs (179 + 1)" -> "the whole ansible/ and esphome/ trees", in both the pipeline comment and the README. * "builds 60 kustomizations" -> "builds every kustomization in the tree". * "verified green across all 60 kustomizations" -> "across every kustomization", keeping the as-of-writing hedge that made it a historical claim rather than a live one. * "expected ~60" in the discovery-floor failure message -> "floor is 50", which cites the actual guard on the line above instead of a tree size that drifts away from it. The message already prints the real $count. * "scratch-based (19 MB, 2 layers, no shell)" -> "ships no shell", plus what the reader actually needs: a step on the plain tag fails to START rather than failing a check, which is the confusing symptom. The byte size would have gone stale on the next upstream release. The floor of 50 itself stays — it is a deliberately loose guard against discovery breaking, not a description of the tree, and it is asserted in code where a wrong value fails loudly instead of merely misinforming. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>🤖 Automated review — model
claude-sonnet-5(complexity: normal), commit13798134596471a34b314f538cc8c1f8bb6a74ea.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new offline, path-filtered pipeline that runs four independent checks (kustomize-build,woodpecker-lint,shellcheck,no-digest-pins) on PRs touchingkubernetes/**or.woodpecker/**, plus matching updates to the update-audit agent prompt and the image-automation README documenting why thewoodpecker-clilint image can't be Flux-managed. This is an unusually well self-verified change — I independently re-checked most of the PR's factual claims against the checkout and they all held up (see below). No blocking issues found.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:56,221— the newci-k8s:2026-07-30tag is newer than theci-k8s:2026-05-01pin used everywhere else in the repo (e2e-test.yml,e2e.yml,alert-monitor.yml,issue-fix.yml). That's not a bug — each pipeline pins independently and the PR body documents this image was specifically verified — but it does mean the repo now carries two different dated pins for the same image with no stated reason for the split. Worth a one-line note (or a follow-up) on whether the older pins should be bumped too, so this doesn't read as an oversight to the next reader.Tests
This is CI configuration, not application code, so "tests" here means the checks are self-validating and the PR body documents manual verification (green run on the current tree, and the #443 defect reproduced as rc=1 against the same image). I independently re-verified several of the underlying factual claims against the checkout rather than just trusting the prose:
find kubernetes -name kustomization.yaml→ exactly 60 results, consistent with thecount -lt 50floor inkustomize-build.*.shfiles underkubernetes/, consistent with thecount -lt 1guard inshellcheck.https:///git@) orhelmCharts:, sokustomize-buildreally is offline as claimed.kubernetes/infrastructure/openbao/rotation/*.yaml: onlykustomization.yamlmatchesimage:.*@sha256(it's a comment documenting the rule), and thegrep -v kustomization.yamlfilter inno-digest-pinscorrectly excludes it — confirmed no false positive today.kubernetes/apps/woodpecker/server.yaml:43deployswoodpecker-server:v3.16.0, matching thewoodpecker-cli:v3.16.0-alpinepin — the "CLI matches deployed server" claim in both the pipeline comment and the prompt.md addition is accurate as of this commit.kubernetes/infrastructure/image-automation/update-automation.yaml:31—update.path: ./kubernetestoday, confirming the README's claim that widening it to./would pull in unrelated trees.ansible/**/*.{yml,yaml}= 179 files,esphome/**/*.{yml,yaml}= 1 file → 180 total, matching the corrected count in both the README and prompt.md additions (and matching the most recent commit on this branch, which fixed this exact number from 197).I did not execute
kubectl kustomize,woodpecker-cli lint, orshellcheckmyself (not available in this environment), so the runtime behavior of the three container-image-dependent steps rests on the PR author's stated verification rather than something I reproduced.Recommendation
Looks reasonable — no blocking issues; the suggestion above is optional.
Correcting 197 → 180 in the previous commit was the wrong fix.
ba052332deletes the number instead.A count that has to be re-derived every time the tree changes doesn't belong in a comment at all — it's stale the moment anything is added, and it was never the argument here. Widening
update.pathis pointless because Flux can't patch non-Kubernetes YAML at all; the size of the walk was a secondary aside. That aside consumed two review rounds (one to flag that 197 didn't reproduce, one to correct it), neither of which touched anything load-bearing.Swept every snapshot figure I'd introduced, not only the flagged one:
180 unrelated ansible/esphome YAMLs (179 + 1)the whole ansible/ and esphome/ trees(comment + README)builds 60 kustomizationsbuilds every kustomization in the treeverified green across all 60 kustomizationsacross every kustomization, keeping the as-of-writing hedgeexpected ~60in the floor failure messagefloor is 50— cites the actual guard on the line above, not a tree size that drifts away from itscratch-based (19 MB, 2 layers, no shell)ships no shell, plus the symptom that actually helps: a step on the plain tag fails to start rather than failing a checkThe
-lt 50floor stays. That one is a deliberately loose guard asserted in code, where a wrong value fails the build loudly — as opposed to a number in a comment, which just misinforms quietly. That distinction is the general rule I should have applied from the start: if a count matters, assert it where drift breaks something; if it doesn't, don't write it down.Picking up the review for
13798134(superseded by two commits since, but its 🟡 point was still open).ci-k8stag split — you're right that it reads as an oversight, because it partly is: the other four pins are simply stale.e2e-test.yml:7,e2e.yml:33,alert-monitor.yml:45andissue-fix.yml:52all sit on the older tag, and per the latest-stable rule all five should be on the newest.I did not bump them here, deliberately. None of those four are triggered by this PR — they're cron- or event-driven and exercise different tooling inside the image — so bumping them in this branch would ship four untested changes under cover of a green run that never touched them. That's the exact shape of the digest decay in #458, where the breakage sat unnoticed for months precisely because the affected jobs didn't run. Each wants its own verification.
Tracked as #461, with a comment above
kustomize-buildexplaining the split where a reader meets it (b1f5d6dc).Two notes on your verification section, since some of it no longer applies:
180figure you re-derived and confirmed has since been deleted rather than corrected (ba052332). It was a snapshot that would be wrong as soon as anything is added to those trees, and it was never the argument — Flux can't patch non-Kubernetes YAML at all, so the size of the walk was a secondary aside. Same sweep removed60 kustomizations,19 MB, 2 layers, andexpected ~60(nowfloor is 50, citing the actual guard). Worth knowing that re-deriving those numbers is wasted effort on this file going forward — if a count matters it should be asserted in code where drift fails the build, as the-lt 50floor is.60/6/ no-remote-bases / self-matching-grep checks all still hold and were the useful half — those are properties, not snapshots.🤖 Automated review — model
claude-sonnet-5(complexity: normal), commitb1f5d6dcbc5fa42e33457904edcbf87ee18b91ea.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new PR-gated pipeline with four parallel, offline checks overkubernetes/**and.woodpecker/**(kustomize build, woodpecker-cli lint, shellcheck aterrorseverity, and a digest-pin guard for the openbao rotators), plus supporting doc updates inci/agents/update-audit/prompt.mdandkubernetes/infrastructure/image-automation/README.md. I checked the concrete, checkable claims against the repo checkout — kustomization count (60, floor is 50 ✓), shell-script count (6, matches "all 6 are clean" ✓), the BusyBoxfindinci-k8s's base image (alpine:3.21 with nofindutilsinstalled, so-printfreally would fail ✓), therotation/kustomization.yamlself-match for the@sha256grep (confirmed, the filter is load-bearing ✓), thedepends_on: []parallel-step convention (matches existing usage inbuild-ci-images.yml✓), and that no kustomization in the tree pulls remote bases or Helm charts (sokubectl kustomizereally is offline for all 60 ✓). Everything checks out; I found no blocking issues.🟡 Suggestions
ci-manifests-test.yml:196— theshellcheckstep's discovery floor iscount -lt 1(i.e., "at least one script found"), far weaker thankustomize-build's floor of 50. That's proportionate today (only 6 scripts exist), but unlike the kustomize floor it wouldn't catch a partial-discovery regression (e.g. a futurefindfilter that only matches half the tree) — it would only catch total discovery failure. Not worth blocking on given the small, slow-changing script count, but worth keeping in mind if thekubernetes/tree grows a lot more shell.ci-manifests-test.yml:69,161,188,234— the three third-party image pins (ci-k8s:2026-07-30freshly built,woodpecker-cli:v3.16.0-alpine,shellcheck-alpine:v0.11.0) and the/bin/woodpecker-clibinary path / working/bin/shclaim are asserted in the comments as empirically probed, but I have no way to pull images or re-run the pipeline from this checkout to confirm them independently. If CI is green on this PR's own run, that's the real confirmation; if it isn't, start there.Tests
This is CI configuration for a homelab GitOps repo — there's no unit-test harness for Woodpecker pipeline YAML itself, and the PR description documents that each step was manually verified both for the pass case (current tree) and the specific failure case it targets (the
#443YAML-scalar bug for lint,-printfsilent-no-op and subshell-swallowed failures for the discovery/loop pattern, the rotation-dir self-match for the digest guard). That's the appropriate level of verification for this kind of change; I independently re-confirmed the parts of it that are checkable from the static checkout (counts, image base packages, self-match), and they hold up. Nothing further to ask for here.Recommendation
Looks reasonable — no blocking issues; comments above are optional.
Both points addressed in
39dc23a9.Image pins /
/bin/sh//bin/woodpecker-cliunverifiable from a static checkout — you called the right test: CI green on this PR's own run. It is. Pipeline 3185 onb1f5d6dc, all four steps green, and each did real work rather than passing vacuously:kustomize-build→ 60oklines (soci-k8s:2026-07-30pulls)woodpecker-lint→ 18oklines, one per.woodpecker/*.yml(sov3.16.0-alpinehas a working/bin/shand/bin/woodpecker-cli— the loop couldn't produce those lines otherwise)shellcheck→ 6oklines (soshellcheck-alpine:v0.11.0pulls)shellcheck floor of 1 vs kustomize's 50 — real asymmetry, kept deliberately, now with the reasoning in the file rather than left to look like an oversight.
Your floor of 50 works because it's loose relative to the tree it guards: that slack is what lets it catch gross partial loss without tripping on churn. The shell-script set is small enough that any floor tight enough to catch partial loss would sit inside normal churn — delete one script and CI fails spuriously, and the fix a hurried person reaches for is lowering the floor. That's how a guard becomes decoration.
Put differently: a floor that has to be edited whenever the tree changes isn't a guard, it's a snapshot with an exit code — and this file just had all its snapshot numbers stripped out for exactly that reason. So the floor stays at 1, catching the failure that actually happened here (discovery silently returning nothing, step green having checked no files), with a note to revisit if
kubernetes/grows a lot more shell.Consistent with that, the 60/18/6 counts above are cited as run-time evidence in the commit message — not written into the file.
🤖 Automated review — model
CLI default(complexity: complex), commit39dc23a9993cf97de799c4bc13a7ba85b0011e7a.Summary
Adds
.woodpecker/ci-manifests-test.yml, a new pull-request pipeline that runs four offline, parallel checks (kustomize-build,woodpecker-lint,shellcheck,no-digest-pins) againstkubernetes/**and.woodpecker/**, plus matching updates to the update-audit agent prompt and the image-automation README documenting that the newwoodpecker-clipin can't be enrolled in Flux image-automation. I checked every factual claim in the diff against the actual checkout (kustomization/script counts, thekustomization.yamlself-match trap for the digest grep, theci-k8stag split across other pipelines, the deployedwoodpecker-serverversion and its3.xauto-bump range, absence of remote bases/helmChartsthat would break offlinekubectl kustomize, and thedepends_on: []parallel-step convention already used inbuild-ci-images.yml) and all of them check out. No blocking issues.🟡 Suggestions
.woodpecker/ci-manifests-test.yml:80and:192—dirs=$(find kubernetes -name kustomization.yaml | sed '...' | sort)andfiles=$(find kubernetes -name '*.sh' | sort)run underset -euwithoutpipefail(ash doesn't support it anyway). Iffinditself ever errored (permission issue, path typo), the command substitution's exit status issort's, notfind's, so the error would be swallowed rather than trippingset -e— the discovery-floor check would still likely catch a resulting empty/short list, but a partial silent failure (e.g.finderroring on one subtree but still emitting output for others) wouldn't be distinguished from a genuinely smaller-but-valid result. Given the step's own stated philosophy is "refusing to report success" on broken discovery, this is a small gap in that guarantee — not worth blocking on since the floor checks already catch the realistic failure modes, but worth a one-line comment if you want the reasoning as airtight as the rest of the file.event: pull_request+path:combination (ci-manifests-test.yml:26-29) has no other precedent in this repo's.woodpecker/*.yml(existingpathfilters are all onpush). The PR's own last commit message cites pipeline 3185 as having fired and passed on this exact combination, which is good evidence it works — just flagging that it's a new pattern here in case that run isn't easily re-checkable by other reviewers.Tests
This PR is the test infrastructure — there's no separate test suite to add. The author states pipeline 3185 ran all four steps green against the real counts (60 kustomizations, 18 pipeline configs, 6 shell scripts), which I independently confirmed match the current tree (
find kubernetes -name kustomization.yaml→ 60,find kubernetes -name '*.sh'→ 6). That's reasonable verification for a CI-definition change. Theci/agents/update-audit/prompt.mdandREADME.mdchanges are documentation/prompt text with no automated check, but I read them for internal consistency (item numbering, image list, drift-tracking cross-references) and found no contradictions with the rest of those files.Recommendation
Looks reasonable — no blocking issues; comments above are optional.