[Automated] Update pulumi CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to pulumi 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

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[claude]

Automated PR Review - Pulumi CLI Options Update

This PR is generated by the ModularPipelines.OptionsGenerator and adds the --otel-traces flag (OpenTelemetry traces export endpoint) across 100 Pulumi command options classes. The change is consistent and mechanically correct. A few architectural observations worth noting:

---

Primary Concern: Global Flag Duplication Instead of Inheritance

The most significant pattern to call out is that --otel-traces is being added individually to every single one of ~100 command-specific options classes, rather than to the PulumiOptions base class.

Looking at PulumiOptions.Generated.cs, the base class is currently empty:

[CliTool("pulumi")]
public abstract record PulumiOptions : CommandLineToolOptions
{
}

Yet flags like --non-interactive, --profiling, --tracing, and now --otel-traces appear identically in every subcommand options class. These are Pulumi global flags (they appear in pulumi --help's Flags: / Global Flags: section and are inherited by all subcommands).

Why this matters architecturally:

• When Pulumi adds or modifies another global flag in a future release, the generator will again produce a diff touching 100+ files
• Consumers setting OtelTraces on a PulumiUpOptions instance cannot do so via the PulumiOptions base type, reducing polymorphic usability
• The generated code is harder to inspect — it's not clear which options are "global" vs command-specific without reading each file

Better approach: The generator's PulumiOptions (or the CobraCliScraper base class) should detect global flags at the root command level and emit them once on the base class, suppressing them from subcommand classes via deduplication during generation. The ParseOptions method in CobraCliScraper.cs already has a seenOptions deduplication set within a single command — the same logic could be extended cross-command for global flags identified from the root --help output.

---

Minor: OtelTraces Type Could Be More Descriptive

The property is typed as string?:

[CliOption("--otel-traces", Format = OptionFormat.EqualsSeparated)]
public string? OtelTraces { get; set; }

The description says it accepts file:// paths or grpc:// endpoints. While string? is pragmatic and the generator cannot infer a richer type from CLI help text alone, this is a case where a future manual extension (the pattern already supported by the codebase for non-generated overrides) could provide a typed wrapper — e.g., a Uri-validated helper — for better discoverability.

---

What the PR Gets Right

• The change itself is mechanically correct: the [CliOption] attribute, OptionFormat.EqualsSeparated, and the XML doc comment are all consistent with every other option in the generated files
• The AssemblyInfo.Generated.cs timestamp bump correctly signals regeneration
• Auto-merge via squash is the right strategy for automated dependency PRs like this
• The generator's CobraCliScraper approach of parsing --help output directly (rather than scraping web docs) is sound and ensures the generated options stay in sync with whatever version of pulumi is actually installed in CI

---

Summary: The PR is safe to merge as-is. The architectural note above about global flags in the base class is a generator-level improvement opportunity, not a blocker for this PR.

[claude]

Follow-up Review (2026-03-22 regeneration)

This PR has been regenerated since the previous review on 2026-03-15. The regeneration updated the AssemblyInfo.Generated.cs timestamp from 2026-03-08 to 2026-03-22.

Previous Concern: Still Open

The architectural note from the prior review remains unaddressed (expected, since it's a generator-level change, not something this PR can fix):

Global flag --otel-traces is duplicated across ~100 classes instead of being declared once on the PulumiOptions base class.

The PulumiOptions base is still empty, and flags like --non-interactive, --profiling, --tracing, and now --otel-traces continue to be repeated verbatim in every subcommand class. The recommendation stands: the generator should detect global flags from the root pulumi --help output and emit them to the base class, deduplicating them from subcommand classes.

This is not a blocker for this PR — it's a generator improvement that would reduce future PR noise.

Change Assessment

The regeneration itself is clean:

• No functional difference from the previous iteration; the content added (OtelTraces / --otel-traces) is unchanged
• Timestamp-only delta in AssemblyInfo.Generated.cs is expected and correct
• Two files (PulumiOrgSearchAiOptions.Generated.cs, PulumiOrgSearchOptions.Generated.cs) correctly show no changes, indicating the generator was idempotent for those commands

Safe to merge.

[claude]

Review (2026-03-29 regeneration)

This is the third regeneration of this automated PR. The timestamp in AssemblyInfo.Generated.cs advances from 2026-03-08 (main) to 2026-03-29 (PR head), confirming a clean fresh generation.

What's New Since Last Review (2026-03-22)

One meaningful content change appeared alongside the continued OtelTraces additions:

PulumiStateDeleteOptions and PulumiState.Generated.cs description update:

-/// Deletes a resource from a stack's state
+/// Deletes one or more resources from a stack's state

This is a small but correct improvement — pulumi state delete accepts multiple URNs, so the updated description accurately reflects the command's capability. The service wrapper in PulumiState.Generated.cs was updated in sync, which is consistent.

---

Prior Architectural Concern: Still Open (Expected)

The recommendation from the 2026-03-15 review remains outstanding:

Global flags like --otel-traces, --non-interactive, --profiling, and --tracing are duplicated across ~100 subcommand classes instead of being promoted once to the PulumiOptions base class.

This is still a generator-level improvement, not a blocker for merging this PR. When Pulumi adds the next global flag, we'll see another 100-file diff.

---

Assessment

The generation is mechanically correct and internally consistent across all 102 files. The PulumiStateDelete description fix is a welcome accuracy improvement. Safe to merge.

[claude]

Review (2026-04-05 regeneration)

This is the fourth regeneration of this automated PR. The AssemblyInfo.Generated.cs timestamp advances from 2026-03-08 (main) to 2026-04-05 (PR head), confirming a fresh full regeneration.

New Content Since Last Review (2026-03-29)

Three meaningful additions appeared alongside the continued OtelTraces propagation:

1. New command: pulumi policy analyze (PulumiPolicyAnalyzeOptions)

A brand new options class and corresponding PulumiPolicy.Analyze() service method have been generated. This is a genuine new command surfaced by the updated Pulumi CLI and is correctly modelled — [CliSubCommand("policy", "analyze")], --policy-pack with AllowMultiple = true, and --policy-pack-config with AllowMultiple = true are all appropriate for this command.

One minor observation: the generated PulumiPolicy.Analyze() service method signature uses PulumiPolicyAnalyzeOptions options = default (i.e., a C# default literal rather than null). This is consistent with every other method in PulumiPolicy.Generated.cs and is fine from a correctness standpoint — default for a reference type is null — but it differs from the common convention of = null and may surprise consumers. This is a generator-wide pattern, not specific to this PR.

2. New flag: --urns added to 6 operation commands

PulumiDestroyOptions, PulumiPreviewOptions, PulumiRefreshOptions, PulumiUpOptions, PulumiWatchOptions, and PulumiStateUpgradeOptions now each include:

[CliFlag("--urns")]
public bool? Urns { get; set; }

This is a Pulumi 3.x command-specific flag (not a global flag), so per-class placement is correct here — unlike --otel-traces, --urns is not in pulumi --help's global flags section. The flag is semantically meaningful only for mutation/query commands, and the generator correctly limited it to those.

3. Doc fix: pulumi state delete description

Carried forward from the 2026-03-29 regeneration — the improvement from "Deletes a resource" to "Deletes one or more resources" is still present and correct.

---

Persistent Architectural Concern: Global Flags on Base Class

The recommendation raised in the 2026-03-15 review remains open and worth repeating as this PR again adds 103 near-identical hunks:

The following flags appear identically in every one of the ~100 subcommand options classes but are absent from PulumiOptions (the base class, which remains empty):

• --color
• --cwd
• --disable-integrity-checking
• --emoji
• --fully-qualify-stack-names
• --logflow
• --logtostderr
• --memprofilerate
• --non-interactive
• --otel-traces (newly added by this PR)
• --profiling
• --tracing
• --verbose

Each of these appears in Pulumi's Global Flags: section (visible in pulumi --help) and is inherited by every subcommand. The generator scrapes each subcommand's --help output individually, which includes the global flags in that output — so they end up duplicated in every class.

Why consolidating to the base class matters:

• Future global flags will again generate 100+ file diffs, increasing PR noise and reviewer fatigue
• Consumers who write helpers accepting PulumiOptions (the base type) cannot polymorphically set OtelTraces or NonInteractive, limiting reuse
• The presence of 13 identical properties in every subcommand class obscures which properties are truly command-specific (like --urns, --diff, --policy-pack) versus universal

Suggested generator change: After scraping each subcommand's --help, collect the flags present in the root pulumi --help global section. During code generation, emit those to PulumiOptions once and skip them when generating any subcommand class where the flag would otherwise be a duplicate of a base class member.

This is not a blocker for merging — the generated code is correct and functional as-is. But the next global flag addition will create the same 100-file diff pattern again.

---

Assessment: Safe to merge. The pulumi policy analyze command addition and --urns flag additions are the substantive new content and are correctly generated.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	✅ 0 (≤ 20 complexity)

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}