[Automated] Update gcloud CLI Options

[thomhurst]

Summary

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

[codacy-production]

Not up to standards ⛔

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🔴 Metrics 67 complexity

Metric	Results
Complexity	⚠️ 67 (≤ 20 complexity)

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review: Automated gcloud CLI Options Update

This is an automated PR generated by the OptionsGenerator tool. All files carry the // <auto-generated> header and [GeneratedCode] attribute, so no manual edits should be expected. My review focuses on the generator's output quality rather than asking for hand-edits, but flags issues worth fixing in the generator itself.

---

Naming Inconsistency: GcloudWorkloadidentity vs GcloudWorkloadIdentity

The newly added service classes use a lowercase-merged name (GcloudWorkloadidentity, GcloudWorkloadidentityServiceAgents), while the options records for the same gcloud command group use proper PascalCase (GcloudWorkloadIdentityOptions, GcloudWorkloadIdentityServiceAgentsGenerateOptions).

This is because gcloud workloadidentity is registered as a single unhyphenated token, which ToPascalCase in GeneratorUtils.cs converts to Workloadidentity (capitalizes only the first character, since there is no hyphen separator to split on). The options records are named after the [CliSubCommand("workload-identity", ...)] attribute value, which is correctly hyphenated and round-trips to WorkloadIdentity.

The result is two different naming conventions for the same API surface in the same assembly:

• IGcloud.Workloadidentity (service property) vs GcloudWorkloadIdentityOptions (options record)
• GcloudWorkloadidentity.ServiceAgents.Generate(GcloudWorkloadIdentityServiceAgentsGenerateOptions) — both names appear in the same method signature

This is a generator bug worth fixing: the ToPascalCase call on the raw CLI command name (e.g. workloadidentity) should either use a dictionary of known compound-word gcloud command groups that need manual word-boundary hints, or the generator should derive the class name from the canonical [CliSubCommand] value (where the hyphenated form workload-identity is already available). The latter approach would make class names consistent by construction.

---

Missing <summary> on --regexp Properties

Several newly added List options classes emit a --regexp property without an XML doc comment:

• GcloudComputeCompositeHealthChecksListOptions.Regexp
• GcloudComputeHealthAggregationPoliciesListOptions.Regexp
• GcloudComputeHealthSourcesListOptions.Regexp

This pattern also exists in pre-existing generated files (GcloudComputeForwardingRulesListOptions, GcloudPreviewComputeInstantSnapshotsListOptions, etc.), so this is a pre-existing generator gap rather than a regression in this PR. It would be worth tracking a generator issue to emit the gcloud help text for --regexp ("Regular expression to filter the names of the results") so IntelliSense surfaces something useful.

---

Missing Summaries on Several New Options Properties

In GcloudComputeHealthAggregationPoliciesCreateOptions, these three properties have no <summary>:

[CliOption("--healthy-percent-threshold", Format = OptionFormat.EqualsSeparated)]
public string? HealthyPercentThreshold { get; set; }

[CliOption("--min-healthy-threshold", Format = OptionFormat.EqualsSeparated)]
public string? MinHealthyThreshold { get; set; }

[CliOption("--policy-type", Format = OptionFormat.EqualsSeparated)]
public string? PolicyType { get; set; }

The help text for these was likely not scraped (possibly because the gcloud alpha/beta command is new). This is consistent with how the generator behaves when help text is unavailable, but it degrades discoverability. Again, a generator-level issue to track rather than a manual fix here.

---

Potential Type Imprecision: string? for Numeric Thresholds

HealthyPercentThreshold and MinHealthyThreshold are typed as string?, where an int? or double? would be more appropriate. This matches the generator's conservative fallback when type detection cannot determine the exact type (no description to parse). Not a blocking issue, but worth noting as another generator-level improvement opportunity.

---

Positives

• The GcloudConcurrencyMode enum is well-formed and correctly used in GcloudFirestoreDatabasesUpdateOptions.ConcurrencyMode, replacing a loose string with a type-safe enum. This is the correct approach.
• The lazy-initialized sub-service properties (_compositeHealthChecks ??= new ...) follow the existing established pattern throughout GcloudCompute.Generated.cs and are consistent.
• The GcloudWorkstationsClusters.Update and GcloudSccSources.List additions correctly use options ?? new TOptions() defaulting, matching the rest of the generated service layer.
• Removal of the stale --logging option from GcloudBeyondcorpSecurityGatewaysCreateOptions and cleanup of the --request-id doc comment in GcloudBeyondcorpSecurityGatewaysUpdateOptions are accurate reflections of the upstream CLI change.

---

Summary

The generated output is structurally correct and consistent with the existing patterns. The two items most worth tracking as generator improvements are:

1. Fix the ToPascalCase / naming strategy so that workloadidentity (unhyphenated CLI name) produces WorkloadIdentity rather than Workloadidentity, aligning service class names with options class names.
2. Emit fallback summaries for --regexp and other undocumented flags so IntelliSense is always populated.

Neither issue is introduced new by this PR (the workloadidentity inconsistency is new here, but it originates from a generator behavior that was latent), so this is safe to merge as-is given the automated nature of the changes.