[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

Assembly-wide public API impact

Affected API families: Flux.

• Added APIs: 3
• Removed or changed APIs: 3
• Members with matching names but changed signatures: 0

Breaking changes are present. Consumers may need to update method arguments, option property types or nullability, enum members, and references to removed APIs.

Representative removed or changed members:

• ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility.Internal = 1 -> ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility
• ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility.Private = 2 -> ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility
• ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility.Public = 0 -> ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility

Representative added members:

• ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility.Internal = 2 -> ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility
• ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility.Private = 0 -> ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility
• ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility.Public = 1 -> ModularPipelines.Flux.Enums.FluxBootstrapGitlabVisibility

Command coverage

Command coverage report:

• flux (flux version 2.9.5): 173 commands, tree cce64ef09e13559016b9deee8b350b34916ce2e46c6e248c25ab24ae62a04c00
  • Baseline comparison: 173 commands at flux version 2.9.5 -> 173 commands at flux version 2.9.5

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

Summary by CodeRabbit

• API Updates
  • Updated GitLab visibility option mappings to reflect the current value assignments.
  • Removed outdated API baseline entries for Flux commands and services.
  • Existing Flux functionality remains available through the current public API surface.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-06T05:27:12.710663Z	3a0f831	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 1ef74f4f-5a27-4e5c-8a06-47575c6231b6

📥 Commits

Reviewing files that changed from the base of the PR and between f4bfc2e and 3a0f831.

⛔ Files ignored due to path filters (2)

• src/ModularPipelines.Flux/Enums/FluxBootstrapGitlabVisibility.Generated.cs is excluded by !**/*.generated.*
• src/ModularPipelines.Flux/Generated/Flux.Generation.json is excluded by !**/generated/**

📒 Files selected for processing (2)

• src/ModularPipelines.Flux/PublicAPI.Shipped.txt
• src/ModularPipelines.Flux/PublicAPI.Unshipped.txt

💤 Files with no reviewable changes (1)

• src/ModularPipelines.Flux/PublicAPI.Shipped.txt

Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review.

---

📝 Walkthrough

Walkthrough

The Flux API baseline removes obsolete FluxBootstrapGitlabVisibility entries and records the enum values as Internal = 2, Private = 0, and Public = 1.

Changes

Flux API baseline

Layer / File(s)	Summary
GitLab visibility enum tracking src/ModularPipelines.Flux/PublicAPI.Shipped.txt, src/ModularPipelines.Flux/PublicAPI.Unshipped.txt	The API baselines remove the previous enum value entries and record the revised Internal, Private, and Public values.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Merge Risk: ⚪ Minimal · up to 3a0f8

This updates Flux GitLab visibility enum tracking to the revised values. Consumers may observe the documented breaking enum-value change, but no current merge-blocking implementation risk remains.

Poem

A rabbit checks the enum trail
Old numbers hop beyond the rail
Internal shifts, Private too
Public finds its value new
The API ledger rests in tune

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: an automated update to Flux CLI options. It is concise and specific.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch automated/update-cli-options-flux

---

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

[github-actions]

Review: [Automated] Update flux CLI Options (#4650)

This is a routine, machine-generated regeneration of the flux options package. It's a small, mechanical diff (one enum file, the generation manifest, and the two PublicAPI tracking files), and it follows the project's documented codegen policy: no hand-edits to generated files, and the current CLI output is treated as the source of truth even though it produces a breaking API change here.

What changed: FluxBootstrapGitlabVisibility went from declaration order Public, Internal, Private to Internal, Private, Public. Since these are plain (unnumbered) enum members, this reorder silently reassigns the underlying ordinal values (Public was 0, is now 2; Internal was 1, is now 0; etc.), which is exactly why the PR's API-impact scan reports 3 removed + 3 added members even though the actual set of allowed values (internal/private/public) hasn't changed at all.

Finding: enum ordering isn't stable across regenerations, and shouldn't be tied to ordinal values

I traced how the emitted order is used at runtime: CommandArgumentBuilder.ParseEnum (src/ModularPipelines/Helpers/Internal/CommandArgumentBuilder.cs) resolves the CLI string via GetField(rawValue.ToString()) → EnumValueAttribute, i.e. by member name, never by ordinal. So this reorder has zero effect on the actual flux bootstrap gitlab command line that gets built — it's a pure ordinal/API-surface artifact of EnumGenerator.GenerateEnum (tools/ModularPipelines.OptionsGenerator/.../Generators/EnumGenerator.cs), which emits members in whatever order CliEnumDefinition.Values arrives in, with no sort.

Other Flux enums scraped from the same CLI version (e.g. FluxBootstrapGitlabSshKeyAlgorithm: Rsa, Ecdsa, Ed25519) kept a stable, non-alphabetical order, while this one flipped between two scrapes of the same flux version 2.9.5. That strongly suggests the upstream CLI itself doesn't guarantee a stable ordering for this particular flag's "allowed values" list (a common symptom of Go's intentionally-randomized map iteration order leaking into generated help/validation text), rather than anything intentional changing on the flux side.

Because the generator faithfully mirrors scrape order into declaration order (and thus ordinal values), any enum with this characteristic will keep yo-yo-ing between orderings on every future scheduled regeneration — each time reported as a "breaking change" (removed/added members) in the PR description, even though nothing about the tool's actual behavior changed. That's noisy for reviewers and erodes the signal value of the breaking-change report for genuine breaking changes.

Suggested fix (in the generator, not this PR): have EnumGenerator sort CliEnumValues deterministically before emitting them — e.g. by CliValue ordinally/alphabetically — instead of preserving raw scrape order. Since runtime CLI-argument resolution only ever depends on the [EnumValue] attribute and member name (never on ordinal position), this would fully preserve behavior while making the emitted ordinal values stable and reproducible across regenerations, for every tool, without needing per-scraper special-casing. This is a generic fix that benefits all generated enums, in line with the project's stated preference for fixing generator/scraper logic rather than generated output.

This doesn't block this specific PR — the generated files here are a correct reflection of the generator's current (order-preserving) behavior — but it's worth tracking as a follow-up so future auto-PRs for this enum (and any other CLI whose help text has unstable ordering) stop reporting phantom breaking changes.

[thomhurst]

The bot review's only finding (unstable enum member order from raw scrape order, phantom removed/added members on every regeneration) is a generator-level follow-up, now tracked as #4660. Per the review body it does not block this regeneration, which correctly mirrors the generator's current behaviour.

@claude please re-review exact head 9be65aa with #4660 as the tracked follow-up.

[thomhurst]

The finding is accurate but generic: EnumGenerator emits members in scrape order and flux does not order this flag's allowed values stably, so the ordinals yo-yo between regenerations. It is now tracked as #4661 (deterministic member ordering in the shared generator; prior-ordinal preservation was removed on purpose in #4404, so the fix is sort-on-emit, not restoration). This PR's generated files are a correct reflection of the generator's current behaviour and are left as generated. @claude please re-review this exact head with #4661 as the disposition for the ordering finding.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6b8a2727a2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[thomhurst]

Correction: the enum-ordering follow-up is tracked as #4661 (#4660 was a concurrent duplicate and is closed).

[github-actions]

Code review

Re-reviewed at head 6b8a2727a28ba306f62baf54140dbae4a8e0198a. The diff is unchanged in kind from the previous review: still just the four generated files (FluxBootstrapGitlabVisibility.Generated.cs, Flux.Generation.json, PublicAPI.Shipped.txt, PublicAPI.Unshipped.txt), and the only content change is another reordering of FluxBootstrapGitlabVisibility's members (now Private, Public, Internal → ordinals 0, 1, 2).

This is the exact same finding already raised and dispositioned: the flux CLI doesn't emit a stable order for this flag's allowed values across scrapes, so EnumGenerator (which preserves scrape order into declaration order, unsorted) reassigns ordinals on every regeneration even though the actual accepted values (internal/private/public) never change. Runtime resolution goes through [EnumValue] by name, not ordinal, so this has no behavioral effect — it's purely enum-declaration churn. Per the maintainer's comments, this is tracked as a generator-level follow-up (#4660/#4661: sort enum members deterministically on emit) rather than something to fix in this generated-output PR.

Cross-checked internal consistency: PublicAPI.Unshipped.txt's added ordinals (Internal = 2, Private = 0, Public = 1) match the new declaration order in the .Generated.cs enum, and the removed entries correctly match the prior shipped ordinals. Nothing else changed.

No actionable issues for this PR — it's a correct, mechanical reflection of the generator's current (order-preserving) behavior, consistent with CLAUDE.md's policy of treating current tool output as source of truth and not hand-patching generated files.

[github-actions]

Code review

No changes since the last review — the PR head is still 6b8a2727, identical to what was already reviewed and cleared in the previous comment.

Confirmed the diff is unchanged: four generated files only (FluxBootstrapGitlabVisibility.Generated.cs, Flux.Generation.json, PublicAPI.Shipped.txt, PublicAPI.Unshipped.txt), with the only content change being the reordering of FluxBootstrapGitlabVisibility's members. As established in the prior review, this reorder has no runtime effect since enum resolution goes through [EnumValue] by name (see CommandArgumentBuilder.ParseEnum), not by ordinal — it's purely enum-declaration churn caused by the flux CLI not emitting a stable order for this flag's allowed values across scrapes. The generator-level fix (sorting enum members deterministically on emit) is tracked as a follow-up per the maintainer's comments (#4661), so it's correctly out of scope for this generated-output PR.

No actionable issues. This is a correct, mechanical reflection of the generator's current behavior, consistent with CLAUDE.md's policy of treating current tool output as source of truth and not hand-patching generated files.

[github-actions]

Code review

Head 3a0f8312 differs in SHA from the previously reviewed/cleared 6b8a2727, but the tree content is identical — this is the same regeneration output, just re-pushed (likely a rebase/re-run by the automated bot rather than new changes). The diff is still exactly four generated files: FluxBootstrapGitlabVisibility.Generated.cs, Flux.Generation.json, PublicAPI.Shipped.txt, PublicAPI.Unshipped.txt, with the only content change being FluxBootstrapGitlabVisibility's members reordered to Private (0), Public (1), Internal (2) — matching what was already reviewed.

This is the same finding already raised, discussed, and dispositioned on this PR:

• The flux CLI doesn't emit a stable order for this flag's allowed values across scrapes, so EnumGenerator (which preserves scrape order into declaration order, unsorted) reassigns ordinals on every regeneration even though the actual accepted values (internal/private/public) never change.
• I independently re-verified the runtime-safety claim: CommandArgumentBuilder.ParseEnum (src/ModularPipelines/Helpers/Internal/CommandArgumentBuilder.cs:680-690) resolves the CLI string via rawValue.ToString() → GetField(name) → EnumValueAttribute.Value, i.e. purely by member name, never by ordinal. So this reorder has no effect on the actual flux bootstrap gitlab command line built at runtime — it's pure enum-declaration/ordinal churn.
• The generator-level fix (sort CliEnumValues deterministically on emit, e.g. by CliValue) is tracked as a follow-up per the maintainer (Generated enum members follow unstable scrape order; emit them deterministically #4661; Emit generated enum members in a deterministic order #4660 was a closed duplicate), consistent with CLAUDE.md's policy of fixing generator/scraper logic rather than hand-patching generated output.

PublicAPI.Unshipped.txt's added ordinals (Internal = 2, Private = 0, Public = 1) correctly match the new declaration order in the .Generated.cs enum, and the removed entries correctly match the prior shipped ordinals. Nothing else changed in this push.

No actionable issues. This remains a correct, mechanical reflection of the generator's current (order-preserving) behavior, and the previously-raised ordering concern is already tracked separately rather than being something to fix in this generated-output PR.

[github-actions]

Review: [Automated] Update flux CLI Options (#4650)

This is the routine automated regeneration of the flux options package (enum reorder + generation manifest hash + PublicAPI tracking updates). It's a small, purely mechanical diff produced by the codegen pipeline, and it correctly follows this repo's codegen policy: no hand-edits to generated files, and the current CLI scrape is treated as the source of truth even though it produces a nominal breaking change here.

What changed: FluxBootstrapGitlabVisibility reordered from Public, Internal, Private to Private, Public, Internal, which reassigns the underlying ordinal values even though the set of allowed values (internal/private/public) is unchanged. PublicAPI.Shipped.txt/Unshipped.txt were updated to match, consistent with the generator's baseline-tracking behavior.

A previous review on this PR already traced the root cause: EnumGenerator.GenerateEnum (tools/ModularPipelines.OptionsGenerator/.../Generators/EnumGenerator.cs) emits enum members in raw scrape order with no sort, and the upstream flux CLI apparently doesn't guarantee a stable order for this flag's value list across scrapes of the same tool version. I re-checked EnumGenerator.cs on the current base branch — it's unchanged, still order-preserving with no deterministic sort — so this will keep yo-yo-ing on future scheduled regenerations, each time reported as a spurious breaking change. Runtime behavior is unaffected either way, since CommandArgumentBuilder.ParseEnum resolves the CLI string via the [EnumValue] attribute/member name, never by ordinal.

That fix belongs in the generator (sort CliEnumValues deterministically, e.g. by CliValue, before emitting), not in this auto-generated PR, so it doesn't block this PR — the generated files here correctly reflect the generator's current behavior. Flagging again mainly so the follow-up isn't lost, since it directly affects the signal quality of the "breaking API changes" section on future auto-PRs for this enum.

No other issues found; this PR is safe to merge as-is.