[Automated] Update az CLI Options

[thomhurst]

Summary

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

Code Review

This is a small automated PR with two changes to auto-generated files. Overall the PR is doing exactly what it says — regenerating az CLI options from the latest help output.

What Changed

1. AssemblyInfo.Generated.cs — Generation timestamp bumped from 2026-04-26 to 2026-05-03. Expected and correct.

2. AzMysqlFlexibleServerRestoreOptions.Generated.cs — The XML doc comment for RestoreTime has its embedded Default: value updated from 2026-04-26T03:26:32 to 2026-05-03T03:27:59.

---

Issue: Generator embeds a volatile default timestamp into doc comments

The az CLI's --restore-time help output reports the current time at the moment the CLI is invoked as its default. The generator faithfully copies that live value into the doc comment:

/// The point in time in UTC to restore from (ISO8601 format), e.g., 2017-04-26T02:10:00+00:00The default value is set to current time.  Default: 2026-05-03T03:27:59+00:00.

This creates noise on every generator run — a diff will appear even when the CLI itself has not changed — and the embedded timestamp is misleading to users (it looks like a stable default but it just reflects when the generator happened to run).

Suggested fix in the generator: When the scraped default value is an ISO 8601 datetime that changes on every invocation, strip it and emit only the stable textual description ("current time"). The sentence "The default value is set to current time" already conveys the correct semantics; the specific timestamp adds no value.

---

Pre-existing concern (not introduced by this PR)

RestoreTime is typed as bool? despite representing an ISO 8601 datetime:

[CliFlag("--restore-time")]
public bool? RestoreTime { get; set; }

This is clearly incorrect — the property should be string? or DateTimeOffset?. This appears to be a generator type-inference bug where datetime-valued options are misclassified as flags. Worth tracking separately as it would cause incorrect CLI invocations (the flag would be emitted without a value).

---

Summary

The PR itself is valid and the automation is working as designed. The two concerns above are generator-level improvements worth addressing:

1. Strip volatile runtime timestamps from generated doc comments to reduce churn.
2. Fix the type-inference logic so datetime CLI options are not emitted as bool?.

[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

_{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.}