[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

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

[claude]

Code Review

This PR is an automated update for the flux CLI options generator. The diff is a single-line timestamp bump in AssemblyInfo.Generated.cs — no options classes actually changed. That makes the PR functionally a no-op but exposes a structural gap in the generator/CI workflow that will keep producing these false-positive PRs indefinitely.

---

Finding 1 (Root Cause) — tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/GeneratorUtils.cs:85

DateTime.UtcNow always guarantees a file diff, defeating the "no meaningful changes" guard.

// GeneratorUtils.cs line 85
sb.AppendLine($"[assembly: AssemblyMetadata(\"ModularPipelines.OptionsGenerator.GeneratedAt\", \"{DateTime.UtcNow:O}\")]");

Every generator run writes a new wall-clock timestamp. The CI guard at .github/workflows/generate-cli-options.yml:535 uses --ignore-all-space --ignore-blank-lines, but the timestamp change is neither whitespace nor blank — so it always passes. A PR is always created even when the flux CLI itself has not changed at all.

Better approach: Only update the timestamp (or the AssemblyInfo file at all) when there are actual option changes. One clean option: write the AssemblyInfo only after diffing all other generated .cs files first, or exclude AssemblyInfo.Generated.cs from the staged diff guard and from the git add glob so it doesn't influence PR creation.

---

Finding 2 — .github/workflows/generate-cli-options.yml:527–541

The guard stages AssemblyInfo.Generated.cs before checking for changes, so the check can never suppress a timestamp-only PR.

# line 532 — stages ALL .cs files, including AssemblyInfo.Generated.cs with its new timestamp
git add 'src/**/*.cs'

# line 535 — guard runs after staging, so the timestamp diff is already included
if git diff --staged --quiet --ignore-all-space --ignore-blank-lines; then

The staging and the guard are logically coupled in the wrong order. By the time the guard runs, the timestamp change is already staged and the condition can never short-circuit.

Better approach: Either stage only non-AssemblyInfo files for the guard check (git add 'src/**/*.cs' ':!**/AssemblyInfo.Generated.cs'), or run the guard before the git add, diffing the working tree against HEAD.

---

Finding 3 — .github/workflows/generate-cli-options.yml:556–571

The PR body template is factually wrong for timestamp-only runs.

The boilerplate says:

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

None of these are true here. The only change is a timestamp. This is misleading for any reviewer or auditor reading the git log, and because auto-merge is enabled (line 583), it lands on main without anyone verifying the mismatch.

Better approach: Generate the PR body dynamically from git diff --staged --name-only output. If the only staged file is AssemblyInfo.Generated.cs, either suppress the PR entirely (preferred) or use a distinct body like "No CLI changes detected; re-generating timestamp only."

---

Summary

The code is otherwise clean and the generated file itself is fine. The issue is that the generator always touches AssemblyInfo.Generated.cs regardless of whether any real options changed, and the CI guard cannot catch this. The fix should be at the root: either skip writing the GeneratedAt timestamp when there are no other changes, or exclude it from the diff guard. That would eliminate this class of noise PR entirely.

[claude]

Code Review

This PR is an automated update for the flux CLI options generator. The diff is a single-line timestamp bump in AssemblyInfo.Generated.cs — no options classes actually changed. That makes the PR functionally a no-op but exposes a structural gap in the generator/CI workflow that will keep producing these false-positive PRs indefinitely.

---

Finding 1 (Root Cause) — GeneratorUtils.cs:85

DateTime.UtcNow always guarantees a file diff, defeating the no meaningful changes guard.

Every generator run writes a new wall-clock timestamp. The CI guard at generate-cli-options.yml:535 uses --ignore-all-space --ignore-blank-lines, but the timestamp change is neither whitespace nor blank, so it always passes. A PR is always created even when the flux CLI itself has not changed.

Better approach: Only update the AssemblyInfo file when there are actual option changes. Exclude AssemblyInfo.Generated.cs from the staged diff guard and from the git add glob so it does not influence PR creation.

---

Finding 2 — generate-cli-options.yml:527-541

The guard stages AssemblyInfo.Generated.cs before checking for changes, so it can never suppress a timestamp-only PR.

Line 532 stages ALL .cs files including AssemblyInfo.Generated.cs with its new timestamp, then line 535 runs the guard after staging. The timestamp diff is already included and the condition can never short-circuit.

Better approach: Stage only non-AssemblyInfo files for the guard check (git add 'src//*.cs' ':!/AssemblyInfo.Generated.cs'), or run the guard before the git add step.

---

Finding 3 — generate-cli-options.yml:556-571

The PR body template is factually wrong for timestamp-only runs. It claims Updated options classes to reflect latest CLI documentation and Added new commands if any were detected — none of which are true here. With auto-merge enabled (line 583), this lands on main without anyone verifying the mismatch.

Better approach: Generate the PR body dynamically from git diff --staged --name-only output. If the only staged file is AssemblyInfo.Generated.cs, either suppress the PR entirely (preferred) or use a distinct body making clear no CLI changes were detected.

---

The generated file itself is fine. The fix should be at the root in the generator: skip writing the GeneratedAt timestamp when there are no other changes, or exclude it from the diff guard. That would eliminate this class of noise PR entirely.