[Automated] Update flux CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to flux 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: [Automated] Update flux CLI Options

This is a straightforward automated PR with minimal changes — two modified files, 5 additions, 5 deletions. No prior review comments exist to follow up on.

What Changed

AssemblyInfo.Generated.cs: The GeneratedAt timestamp was updated from 2026-03-08T03:08:56.8911964Z to 2026-03-15T03:13:24.5806987Z. This is expected and correct — it reflects that the generator was re-run on a newer date.

FluxBootstrapGitlabVisibility.Generated.cs: The enum member ordering changed:

Before:

Internal, Private, Public

After:

Private, Public, Internal

Assessment

Correctness: The change is correct with respect to the Flux CLI. The --visibility flag for flux bootstrap gitlab accepts private, public, and internal as valid values. All three values remain present; only their order within the enum changed. No values were added or removed.

Breaking change risk: Enum member order in C# does not affect the underlying integer values assigned to members unless explicit integer assignments are used (none are here). Since no explicit values are assigned, all three members will still receive sequential default values (0, 1, 2), but the mapping between names and integers shifts:

Member	Before	After
Internal	0	2
Private	1	0
Public	2	1

This is a potentially breaking change if any consuming code stores or compares the raw integer value (e.g., serializes/deserializes the enum as an integer, or uses (int)FluxBootstrapGitlabVisibility.Private == 1 style comparisons). However, since this library uses [Description] attributes to map enum values to CLI flag strings, and the enum members are named identically, any code that works exclusively with named enum members (FluxBootstrapGitlabVisibility.Private) is unaffected. This is the expected and idiomatic usage pattern in this codebase.

Observation for the generator: The reordering appears to reflect a change in the order Flux CLI outputs the visibility options in its --help text. The generator faithfully mirrors that order, which is consistent with the project's design. That said, it may be worth considering whether the generator should sort enum members alphabetically or by some stable criterion to avoid spurious diffs in future PRs when CLIs reorder their help text without actually adding or removing options. This is a minor suggestion for the generator, not a blocker for this PR.

Verdict

The changes are mechanically correct and safe for the intended use pattern. The auto-merge configuration is appropriate for automated dependency/update PRs of this nature. Approving with the minor observation above noted for future generator consideration.

[claude]

Code Review: [Automated] Update flux CLI Options (Re-run)

This PR was previously reviewed on 2026-03-15. The prior review noted the enum reordering and confirmed it was safe for the intended use pattern. Here's a follow-up assessment of the current diff.

What Changed

AssemblyInfo.Generated.cs: Timestamp updated from 2026-03-08T03:08:56.8911964Z to 2026-03-22T03:12:28.6224553Z. Expected and correct.

FluxBootstrapGitlabVisibility.Generated.cs: Enum ordering changed again — same reordering as the previous run:

Before: Internal, Private, Public
After: Private, Public, Internal

Follow-up on Previous Review

The prior review flagged a minor observation worth revisiting: the generator mirrors the Flux CLI help text order, which leads to spurious diffs when CLIs reorder their output without actually adding/removing options. The recommendation was to consider stable sorting (e.g., alphabetical) in the generator to avoid these noise PRs.

This reordering has now appeared in two consecutive automated runs, suggesting the Flux CLI has permanently changed its help text ordering and the generator will continue producing this diff on every re-run until the sort order is stabilized. Given the [Description] attribute-based usage pattern in this codebase, there is no runtime risk from the reorder — but it may be worth a one-line fix to the generator to sort enum members by their description string.

Verdict

Changes are correct and safe. The auto-merge is appropriate. Consider the generator-side stable-sort improvement to reduce future noise.

[claude]

Code Review: [Automated] Update flux CLI Options (Third Run)

This is the third automated run of this PR. Previous reviews were posted on 2026-03-15 and 2026-03-22. Both prior reviews confirmed the changes were safe and noted a generator-side improvement opportunity.

What Changed This Run

AssemblyInfo.Generated.cs: Timestamp updated from 2026-03-22T03:12:28.6224553Z to 2026-03-29T03:14:12.1304333Z. Expected and correct — it is the only line in the actual diff this time.

FluxBootstrapGitlabVisibility.Generated.cs: No change in this run. The enum reordering that appeared in the previous two runs is not present here, meaning the generated output is already in the Private, Public, Internal order from last time.

Status of Previous Review Observations

Both prior reviews raised the same recurring observation:

The generator mirrors the Flux CLI help text order, which can produce spurious diffs when a CLI reorders its --help output without adding or removing values. Consider sorting enum members by a stable key (e.g., alphabetically by CliValue) in EnumGenerator to eliminate this class of noise PR entirely.

This has not been addressed. I verified the current state of the generator at tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/EnumGenerator.cs. The relevant loop (line 58) iterates enumDef.Values directly in the order they were scraped, with no sorting applied:

for (var i = 0; i < enumDef.Values.Count; i++)
{
    var value = enumDef.Values[i];
    ...
}

The fix would be a one-liner change to that loop: sort enumDef.Values by value.CliValue (or value.MemberName) before iterating. This would make enum member ordering deterministic and independent of the order the CLI tool happens to emit its help text.

Verdict

The current diff is correct and safe — it is a single timestamp update with no functional change. Auto-merge remains appropriate.

However, this is the third consecutive review raising the same generator improvement. If the Flux CLI's help text order continues to oscillate, the next run will produce the same reordering diff again, generating yet another noise PR. The stable-sort fix in EnumGenerator.cs is a low-effort, high-value change worth applying proactively.

[claude]

Code Review: [Automated] Update flux CLI Options (Fourth Run)

This is the fourth automated run of this PR type. Three prior reviews were posted (approximately 2026-03-15, 2026-03-22, and 2026-03-29). All confirmed the changes were safe and raised the same generator-side improvement recommendation.

What Changed This Run

AssemblyInfo.Generated.cs: Timestamp updated from 2026-03-29T03:14:12.1304333Z to 2026-04-05T03:30:36.8691602Z. Expected and correct.

FluxBootstrapGitlabVisibility.Generated.cs: The enum member ordering has changed again — the same oscillation flagged in the first two reviews:

Before: Internal, Private, Public
After: Public, Internal, Private

All three values remain present; this is purely a reordering.

Status of Prior Review Observation — Still Unaddressed

Every prior review raised the same issue: the generator at tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/EnumGenerator.cs iterates enumDef.Values in scrape order with no stable sorting, causing spurious diffs whenever the Flux CLI reorders its --help output. The fix is a one-liner on line 58:

// Current (unstable — order depends on CLI help text output order):
for (var i = 0; i < enumDef.Values.Count; i++)

// Suggested (stable — always alphabetical by CLI value):
var sortedValues = enumDef.Values.OrderBy(v => v.CliValue).ToList();
for (var i = 0; i < sortedValues.Count; i++)

This has been flagged in three consecutive reviews and the Flux CLI's help text order continues to oscillate between runs (it appeared in runs 1, 2, and now 4, but not run 3). Each oscillation generates a new automated PR, a new CI run, and a new review — all for a zero-functional-impact reordering.

Why this matters beyond noise reduction: Unstable enum ordering is a latent risk for any consuming code that serializes the enum as an integer, even if the current dominant use pattern (named member comparison) is safe. Pinning a stable order eliminates that class of risk permanently.

Verdict

The current diff is correct and safe. Auto-merge is appropriate.

That said, this is the fourth consecutive review raising the same generator improvement. At this point the fix is clearly justified — it is a two-line change that permanently eliminates this category of noise PR. I'd encourage applying it to EnumGenerator.cs before the next scheduled run.

[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}