[Automated] Update kustomize CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to kustomize CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Assembly-wide public API impact

No active public API changes were detected in this assembly.

Command coverage

Command coverage report:

• kustomize (v5.8.1): 45 commands, tree 0ae36cae52a7633cdaf6161528ae7819e41d2855a07443c9b69a53279326fb08
  • Baseline comparison: 45 commands at v5.8.1 -> 45 commands at v5.8.1

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (2)

• src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json is excluded by !**/generated/**
• src/ModularPipelines.Kubernetes/Options/KustomizeEditFixOptions.Generated.cs is excluded by !**/*.generated.*

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 266aa8bd-9a20-46e5-9e94-46bef5234c6d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Automated Review — PR #4558

Scope check: Confirmed via gh pr diff that this PR touches only 3 files: a new src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json manifest, and updates to src/ModularPipelines.Kubernetes/PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt. No .cs source files change. I cross-checked a large sample of the PublicAPI.*.txt entries against the current generated code at the PR's merge base and confirmed they already match — this baseline was stale before the PR, and this PR is a legitimate mechanical catch-up rather than a new source of drift.

Finding (process/communication risk, not a correctness bug)

Mislabeled scope hides a breaking API change to unrelated (kubectl) surface area.

• File: src/ModularPipelines.Kubernetes/PublicAPI.Unshipped.txt / PublicAPI.Shipped.txt
• What: The PR is titled/described purely as a "kustomize CLI options" update, and the only ignored generated file mentioned by CodeRabbit's own filter is Kustomize.Generation.json. But because PublicAPI.*.txt is scoped to the whole ModularPipelines.Kubernetes assembly rather than per-tool, this diff also formally documents a sizeable breaking change to ~22 kubectl service methods that have nothing to do with kustomize — e.g. IKubernetesRollout.PauseAsync/ResumeAsync/RestartAsync/StatusAsync/UndoAsync/HistoryAsync, IKubernetes.AnnotateAsync/AttachAsync/CordonAsync/CpAsync/DebugAsync/DrainAsync/ExecAsync/LabelAsync/LogsAsync/PortForwardAsync/TaintAsync/UncordonAsync, IKubernetesAuth.CanIAsync, IKubernetesConfig.SetAsync/SetClusterAsync/SetCredentialsAsync. These move options from optional-nullable-with-default (Options? options = null) to required non-nullable, DryRun/Cascade change from string? to strongly-typed enums (KubernetesAnnotateDryRun, KubernetesApplyCascade, etc.), and KubernetesKubercSetPolicy enum members are renamed/recased (Allowall/Denyall → AllowAll/DenyAll).
• Why it matters: A consumer calling e.g. context.Tools.Kubernetes.Rollout.PauseAsync() with no arguments (relying on the previously-optional default) will fail to compile once this baseline lands — but nothing in the PR title, description, or the generation manifest signals that kubectl consumers are affected, since none of the changed methods are kustomize-related.
• Suggested improvement: Either (a) split per-tool PublicAPI.*.txt files (one per generated tool under ModularPipelines.Kubernetes, similar to how Generated/*.Generation.json is already per-tool) so a kustomize-only regeneration can't silently sweep in kubectl's breaking changes, or (b) have the automation that opens these PRs diff the previous PublicAPI.*.txt against the new one and flag/name every tool whose public surface actually changed in the PR body, so reviewers get an accurate breaking-change summary instead of relying on the (currently misleading) title.

No other issues found; the enum renames/recasing and parameter nullability changes that are in scope look like they correctly reflect the current generator/scraper output.

[thomhurst]

Addressed review's immediate communication risk: title/body now name assembly-wide Kubernetes baseline synchronization and enumerate kubectl consumer impact.

Ubuntu failure is unrelated to this generated diff: RunCoreUnitTestsModule hung for ~20 minutes in Timeout_Fault_During_Grace_Period_Counts_As_Response, then hangdump timeout ended the run. Same test/run failure occurred on #4548. Per flaky-test policy, not rerunning merely for green.

Systemic per-tool PR-summary automation remains separate from this generated output PR; no generated files were hand-edited.

[thomhurst]

Systemic automation follow-up filed: #4576

[thomhurst]

The PR title/body now explicitly disclose the assembly-wide kubectl breaking API changes and consumer migration impact identified in review. @claude please re-review the exact head 2f55868 with the corrected scope documentation.

[thomhurst]

@claude The exact-head finding was addressed without changing generated files: the PR title and body now explicitly identify the assembly-wide Kubernetes/kubectl API baseline changes and migration impact, and issue #4576 implements systemic generated PR summaries. Please replace the stale BLOCKING verdict for exact head 2f55868.

[claude]

Automated Review — PR #4558 (re-review at head 577eeb71887fd6165f2fb768a56d1e5adb49041e)

Scope check: gh pr diff confirms this PR still touches only 3 files — the new src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json manifest and updates to src/ModularPipelines.Kubernetes/PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt. No hand-edited .cs files. The generated content itself (enum renames/recasing, DryRun/Cascade moving from string? to strongly-typed enums, constructor-nullability changes) looks like a correct, mechanical reflection of current generator/scraper output, consistent with this repo's policy that "current tool output is the sole source of truth for generated options, even when regeneration causes breaking API changes" (root CLAUDE.md).

Previously raised finding — still present on this head

In the last review (at former head 2f55868b52fd35be4fab2199b3207d7d281e7961), I flagged that this PR is titled/described as a kustomize-only update, but because PublicAPI.*.txt is scoped to the whole ModularPipelines.Kubernetes assembly, the diff also formally ships a breaking change to ~22 kubectl service methods unrelated to kustomize (e.g. IKubernetesRollout.PauseAsync/ResumeAsync/RestartAsync/StatusAsync/UndoAsync/HistoryAsync, IKubernetes.AnnotateAsync/AttachAsync/CordonAsync/CpAsync/DebugAsync/DrainAsync/ExecAsync/LabelAsync/LogsAsync/PortForwardAsync/TaintAsync/UncordonAsync, IKubernetesAuth.CanIAsync, IKubernetesConfig.SetAsync/SetClusterAsync/SetCredentialsAsync) — verified again on this diff, same set of removed/added PublicAPI lines is still present.

In the follow-up comments, you noted the title/body were updated to disclose this and asked me to re-review the corrected scope documentation. However, on the current head (577eeb71887fd6165f2fb768a56d1e5adb49041e, pushed after that comment), the live PR title/body are:

[Automated] Update kustomize CLI Options
"This PR contains automatically generated updates to kustomize CLI options classes... Command coverage report: kustomize (v5.8.1): 45 commands..."

i.e. it's back to the kustomize-only wording with no mention of the kubectl-surface breaking changes — the disclosure doesn't appear to have survived whatever regenerated/re-pushed this commit. This isn't a defect in the generated code (which is correct per the "sole source of truth" policy), just a gap between what was said was fixed and what's actually on this head.

Suggestion: Since manual edits to the PR body seem to get clobbered whenever the branch is regenerated/re-pushed, the durable fix is the systemic one already tracked in #4576 (having the automation itself diff PublicAPI.*.txt and name every affected tool in the generated body) rather than re-editing this PR's description by hand again, since that edit won't survive the next regeneration either. Until that lands, it'd still be worth a quick manual edit to this PR's title/body before merge so consumers relying on the affected kubectl methods aren't surprised.

No other issues found — the in-scope kustomize option changes and the mechanically-generated kubectl-surface changes both look like accurate reflections of current tool output.

[thomhurst]

Regeneration replaced the prior metadata; restored the reviewed assembly-wide Kubernetes/kubectl disclosure on exact head 577eeb7. Systemic durable fix remains PR #4586. @claude please re-review this exact head with the live title/body.

[thomhurst]

@claude Please review this change.

Exact HEAD: 577eeb7. The live title/body now explicitly disclose the assembly-wide Kubernetes/kubectl breaking API changes and consumer migration impact; no generated files changed after your prior review.

[thomhurst]

Synced current main at exact head $(529d2e8.Substring(0,10)). Kustomize provenance still matches the generator on HEAD, and the corrected title/body now explicitly disclose the assembly-wide kubectl breaking baseline changes. @claude please re-review this exact head.

[claude]

Automated Review — PR #4558 (head 529d2e82f4a2e32cb02d9ed54acd8ee7cfeb0cec)

Scope check: gh pr diff confirms this PR touches only 3 files: a new src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json provenance manifest, and updates to PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt. No hand-edited .cs files, consistent with the repo's policy that generated options are never hand-tweaked in a PR.

Previously raised finding — now resolved. Earlier reviews on this PR (at heads 2f55868b… and 577eeb71…) flagged that the title/body only mentioned kustomize while the whole-assembly PublicAPI.*.txt diff also silently shipped ~22 breaking kubectl surface changes. On the current head, the PR body explicitly calls this out under "Consumer impact" ("these baseline changes expose previously generated kubectl breaking API changes even though this refresh was triggered by kustomize... consumers using no-argument kubectl convenience calls or old string/casing forms must update"). That disclosure gap is fixed.

New finding: baseline-sync tooling produces orphaned *REMOVED* bookkeeping in PublicAPI.Unshipped.txt

• What: In this PR's diff, for every removed member the sync deletes the plain entry from PublicAPI.Shipped.txt and, in the same commit, adds a *REMOVED*<same symbol> line to PublicAPI.Unshipped.txt (e.g. KubernetesAnnotateOptions.DryRun.get -> string? is deleted from Shipped.txt line 310 while *REMOVED*KubernetesAnnotateOptions.DryRun.get -> string? is added to Unshipped.txt — same pattern for 43 more entries: KubercSetPolicy.Allowall/Denyall, and constructors/DryRun/Cascade getters across ~20 kubectl option types).
• Why it's wrong: Under the standard Roslyn PublicApiAnalyzers workflow, a *REMOVED* marker in Unshipped.txt is meant to coexist with the still-present entry in Shipped.txt — the pairing only gets collapsed (entry stripped from Shipped, marker cleared from Unshipped) by an actual "ship" step when a release goes out. Here the sync deletes the Shipped.txt entry itself instead of leaving that to the ship step, so the freshly-added *REMOVED* marker has nothing left to refer to from the moment it's committed. This isn't hypothetical: I checked the full current file, and of all ~202 *REMOVED* lines now in PublicAPI.Unshipped.txt, zero correspond to a still-present entry in Shipped.txt.
• Pre-existing, not new to this PR: I traced this back with git log/git show — the pattern was already baked into the very commit that created both files (d8f2344d, #4470), so this PR's automated sync is mechanically continuing an already-broken convention rather than introducing a new bug. This PR does make it worse (44 more dead entries added on top of the ~158 already there), and since every future tool refresh will keep compounding it, it's worth fixing at the source rather than accepting indefinitely.
• Suggested fix: Per this repo's own policy ("fix generated-options problems in the scraper or generator, not in generated output"), the fix belongs in whatever script performs the baseline sync (not in this PR's generated files): either (a) stop deleting entries from Shipped.txt directly and only add *REMOVED* markers to Unshipped.txt, leaving Shipped.txt alone until an actual release "ships" and reconciles the two files, or (b) if the repo doesn't use the ship/unshipped release lifecycle at all and instead treats Shipped.txt as a rolling "current state" snapshot, then drop the *REMOVED* bookkeeping in Unshipped.txt entirely and rely solely on the Shipped.txt diff — carrying both mechanisms at once is what produces entries that can never be reconciled by tooling.

No other issues found — the in-scope kustomize changes and the kubectl-surface changes both look like accurate reflections of current generator/scraper output, and a scoped build of ModularPipelines.Kubernetes.slnx succeeds.

[thomhurst]

The current BLOCKING finding is based on the opposite of Microsoft.CodeAnalysis.PublicApiAnalyzers 5.6.0's documented removal contract. Its bundled RS0017 documentation says: when removing a public type or member, put that entry in PublicAPI.Unshipped.txt with the REMOVED prefix. The repository's sync tests intentionally encode exactly that transition: remove Api.Removed from Shipped and add REMOVEDApi.Removed to Unshipped (Test-SyncPublicApiBaselines.ps1), including idempotency coverage in Test-MergePublicApiBaselineSnapshot.ps1. Both scripts pass on the current head. Keeping the original entry in Shipped would leave a declaration for an API that no longer exists and continue producing RS0017. No code change is appropriate here. @claude please reassess the current head against the analyzer's documented semantics and repository tests.

[thomhurst]

Re-assessed the outstanding finding against the documented PublicApiAnalyzers lifecycle and #4244's intent. The finding is accurate: a *REMOVED* marker is meant to coexist with the still-present Shipped.txt entry until a release ships the unshipped file, and the sync script instead deletes the shipped line immediately, so the marker is orphaned from the moment it lands. The earlier rebuttal here was wrong on one point: the marker is exactly what suppresses RS0017 for a retained shipped entry, so keeping the entry would not keep producing RS0017. The analyzer treats the orphaned markers as inert, which is why this file shape builds clean.

Per this repo's policy the fix belongs in Merge-PublicApiBaselineSnapshot.ps1 / Sync-PublicApiBaselines.ps1 and their tests, not in this PR's generated baselines, and the existing orphaned markers across all packages need a one-time migration in the same change. That is now tracked in #4638 (with the (a)/(b) decision spelled out). This PR remains a mechanically correct sync under the current script and does not hand-edit generated output, so I am leaving its baseline files as generated.

@claude please re-review this exact head with #4638 as the disposition for the sync-tooling finding.

[github-actions]

Automated Review — PR #4558 (re-review at head 529d2e82f4a2e32cb02d9ed54acd8ee7cfeb0cec, no new commits since last review)

Scope check: Unchanged — gh pr diff still shows only 3 files: the new src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json provenance manifest and updates to PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt. No hand-edited .cs files, consistent with this repo's policy of never hand-tweaking generated options.

Disclosure finding — confirmed resolved. The PR body's "Consumer impact" section explicitly discloses the whole-assembly kubectl breaking changes (non-nullable options, typed DryRun/Cascade enums, KubercSetPolicy casing) even though this refresh was triggered by kustomize. That closes the gap flagged in the two earlier reviews on this PR.

Re-examined finding: "orphaned *REMOVED* bookkeeping". A prior review on this exact head flagged that the sync deletes an entry from PublicAPI.Shipped.txt in the same commit that adds *REMOVED*<entry> to PublicAPI.Unshipped.txt, calling this a bug in the baseline-sync tooling. On independent re-reading of tools/ModularPipelines.OptionsGenerator/scripts/Merge-PublicApiBaselineSnapshot.ps1 (not just the PR conversation), this is not a bug — it's the script's deliberate, tested design:

• Lines 67–72 keep a Shipped.txt entry only if it's still current or not in the confirmed-removed set — i.e. a confirmed removal is intentionally dropped from Shipped.txt immediately, not held until a separate "ship" step.
• Lines 81–85 add the matching *REMOVED*<entry> line to Unshipped.txt in that same pass.
• Test-MergePublicApiBaselineSnapshot.ps1 explicitly asserts this exact transition (*REMOVED*Api.Removed() etc.) and separately asserts the merge is idempotent on rerun.

So this repo treats Shipped.txt as a rolling "current API" snapshot rather than a release-boundary snapshot, and uses the *REMOVED* prefix purely as a permanent audit trail of intentional removals rather than a "pending until next ship" marker. That's a valid, self-consistent, and tested variant of the standard PublicApiAnalyzers workflow — not drift or dead bookkeeping. I could not verify the referenced follow-up issue (#4638) via gh in this sandboxed session, but based on the primary source (script + its own test suite) there doesn't appear to be a real defect here for that issue to fix. I'm not carrying this finding forward as blocking.

Content check: Diffed this PR's PublicAPI.Shipped.txt/Unshipped.txt against the current base-branch copies directly (not just via gh pr diff) — they're byte-identical, meaning the whole-assembly baseline in main has already converged to the same state independently (consistent with this being a deterministic function of the current generated code, not something this PR is uniquely introducing). The only genuinely new content is the kustomize provenance manifest, which is well-formed and matches the PR's stated tool/version.

No actionable findings remain on this head.

[thomhurst]

Synced current origin/main at exact head 8c1860b4c1 (conflict-free). The assembly-wide PublicAPI.*.txt baseline changes previously carried here have since landed on main through other merges, so this PR's remaining diff is the Kustomize.Generation.json provenance file only. The sync-tooling finding stays tracked in #4638; the dispatched re-review already returned CLEAR for the prior head, and this push lets the review workflow record that verdict as a review on the current head.

[github-actions]

Code review

Reviewed at head 8c1860b4c1606fb84b81f84417bb7aaca1648fe5.

Independently verified scope: gh pr diff at this exact head shows a single changed file — the new src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json provenance manifest. The PublicAPI.Shipped.txt/PublicAPI.Unshipped.txt changes discussed in earlier rounds of this thread are no longer part of the diff (they've landed on main via other merges), so the previously-tracked sync-tooling finding (now filed as #4638) is not applicable to this head and isn't re-raised here.

Content check: The new file's shape (formatVersion, toolName, toolVersion, commandTreeSha256, generatorSourceSha256) matches the established pattern used by every other tool's *.Generation.json provenance file (e.g. src/ModularPipelines.Kind/Generated/Kind.Generation.json), including the same generatorSourceSha256, confirming this was produced by the same generator run rather than hand-authored. No .cs generated output was hand-edited, consistent with this repo's rule that generated options are never hand-tweaked in a PR.

No issues found. This is a clean, mechanically-generated, single-file provenance update.

[thomhurst]

The orphaned *REMOVED* finding is a sync-script bug rather than something this generated baseline should hand-edit; it is tracked in #4638 and fixed in #4644 (shipped entries are now retained alongside their markers, the change summary subtracts markers, and the fast-fail check rejects orphans). Once that merges, the generator fingerprint changes and this branch regenerates from main in the new shape.

[thomhurst]

The fast-fail lane on the synced head failed in Assert-GeneratedOptionsFreshness.ps1: generator sources on main changed after this kustomize snapshot was produced, so the snapshot is stale by policy (regenerate from current main, do not rebase old generated commits). Dispatched a regeneration from main for the stale automated tools (this one plus buildah, podman, packer, snyk, jq, yarn, eksctl, kind, hadolint, gh, helm, choco, sonar-scanner; argocd stays parked on #4609): https://github.com/thomhurst/ModularPipelines/actions/runs/33999343509. The run refreshes automated/update-cli-options-kustomize in place with fresh provenance, which replaces the manual sync above.

[github-actions]

Review

This is a minimal, well-scoped automated update to the kustomize CLI options generator output. I independently verified the exact HEAD (d65489a8) diff via gh pr diff — it touches exactly 2 files:

1. src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json (new) — a provenance/tracking manifest recording the tool version and scrape hashes. Its schema (formatVersion, toolName, toolVersion, commandTreeSha256, generatorSourceSha256) matches the equivalent files already present for other tools (e.g. Kind.Generation.json, Eksctl.Generation.json), so this is consistent with the established pattern and simply backfills tracking for kustomize.
2. KustomizeEditFixOptions.Generated.cs — a documentation-comment-only change appending a safety recommendation ("We recommend doing this in a clean git repository where the change is easy to undo.") to the Vars option, reflecting updated upstream CLI help text. No signature, type, or behavioral change.

No hand-edits to generated output are present (consistent with the project's rule that generated options must only change via the scraper/generator), no public API surface changes, and no logic changes to review for correctness bugs.

I found no actionable issues — this is a safe, low-risk PR reflecting the current state of the CLI's help text.

[github-actions]

Automated Review — PR #4558 (head 6023e7c7b3b1084911a02b9f43336098e75593d8)

Scope check: gh pr diff confirms this PR now touches only 2 files, a much smaller and cleaner diff than earlier iterations of this PR:

• src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json (new) — a per-tool provenance manifest (toolVersion, command-tree hash, generator-source hash), following the same pattern already used by every other tool package (e.g. Kubernetes.Generation.json, Docker.Generation.json, etc.).
• src/ModularPipelines.Kubernetes/Options/KustomizeEditFixOptions.Generated.cs — a doc-comment-only change to the --vars flag's XML doc, reflecting an updated description string from the upstream kustomize edit fix CLI help text.

No hand-edits to generated output. The change is a straight pass-through of scraped CLI help text into the doc comment — consistent with this repo's policy that generated options are the sole source of truth and should never be hand-tweaked.

No API-breaking surface. Unlike earlier pushes to this same PR (previously reviewed at heads 2f55868b…, 577eeb71…, 529d2e82…), the current head makes no changes to PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt — I diffed both files against main and they are byte-identical. The previously-flagged issues (mislabeled kustomize-only scope silently shipping ~22 breaking kubectl API changes, and orphaned *REMOVED* bookkeeping in PublicAPI.Unshipped.txt) do not apply to this head; the PR appears to have been reset/re-scraped since those reviews and no longer carries that content. Those concerns remain worth tracking generically (per the earlier suggestion to have the automation diff PublicAPI.*.txt and name affected tools, tracked in #4576), but there's nothing outstanding on this PR's current diff.

Verdict: This is a safe, correctly-scoped, mechanical documentation update with no behavioral or public-API impact. No issues found.

[github-actions]

Code review

Reviewed at head f074b57228ca63e87a11115a453ba8a2fba731b5.

Scope check: gh pr diff confirms this PR touches exactly 2 files:

1. src/ModularPipelines.Kubernetes/Generated/Kustomize.Generation.json (new) — a provenance manifest recording tool version and scrape hashes. I compared its shape (formatVersion, toolName, toolVersion, commandTreeSha256, generatorSourceSha256) against the sibling Kubernetes.Generation.json in the same directory — identical schema, confirming this was produced by the same generator rather than hand-authored.
2. KustomizeEditFixOptions.Generated.cs — a doc-comment-only change appending a safety note ("We recommend doing this in a clean git repository where the change is easy to undo.") to the --vars flag's XML doc, reflecting updated upstream kustomize edit fix CLI help text. No signature, type, or behavioral change.

History check: This PR previously went through several rounds where the whole-assembly PublicAPI.*.txt diff bundled in unrelated breaking kubectl changes (flagged BLOCKING) and an orphaned *REMOVED* bookkeeping issue in the baseline-sync tooling (tracked in #4638, fixed in #4644). The branch has since been regenerated from current main, and the current head no longer touches PublicAPI.*.txt at all — those concerns don't apply here. This matches the state that received CLEAR verdicts on the two immediately preceding heads (d65489a8, 6023e7c7), and pr-head/ content matches the diff exactly.

No hand-edits to generated output, consistent with this repo's policy that generated options are the sole source of truth and must only change via the scraper/generator.

No actionable findings on this head.