[Automated] Update go CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to go 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 an automated PR generated by to keep the go CLI options classes up to date.

Change Summary

The diff is minimal — only one line changed in :

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-02-15T03:12:06.6760225Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:12:25.2675306Z")]

The generator ran again and updated the timestamp, but found no changes to the actual go CLI options — no new commands, no removed options, and no updated descriptions.

Assessment

No issues found. This is exactly the expected output for a scheduled generator run where the upstream go tool's CLI surface hasn't changed since the last run (2026-02-15). The timestamp update is useful as evidence that the generator ran successfully and the options are current.

The PR is safe to merge as-is.

[claude]

Code Review

This is an automated PR generated by ModularPipelines.OptionsGenerator to keep the go CLI options classes up to date.

Change Summary

The diff is minimal — only one line changed in src/ModularPipelines.Go/AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-02-15T03:12:06.6760225Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:12:25.2675306Z")]

The generator ran again and updated the timestamp, but found no changes to the actual go CLI options — no new commands, no removed options, and no updated descriptions.

Assessment

No issues found. This is exactly the expected output for a scheduled generator run where the upstream go tool's CLI surface hasn't changed since the last run (2026-02-15). The timestamp update is useful evidence that the generator ran successfully and the options are current.

The PR is safe to merge as-is.

[claude]

Code Review: No issues found. This automated PR only updates the GeneratedAt timestamp in AssemblyInfo.Generated.cs from 2026-02-15 to 2026-03-01. The go CLI options generator ran successfully but detected no changes to the actual CLI surface, so no option classes were modified. This is the expected behavior and the PR is safe to merge.

[claude]

Code Review (Updated — 2026-03-08 Run)

This is a follow-up review for the latest commit, which updated the GeneratedAt timestamp again since the previous review on 2026-03-01.

Change Summary

Only one line changed in src/ModularPipelines.Go/AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:12:25.2675306Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-08T03:09:00.5261984Z")]

Assessment

No issues found. The generator ran successfully on 2026-03-08 and detected no changes to the go CLI surface since the last run. The timestamp-only update confirms that the tooling is working correctly and the generated options classes remain current.

The previous review concerns have all been addressed (none were raised — the prior reviews also gave a clean bill of health). This PR remains safe to merge as-is.

[claude]

Code Review

This automated PR updates the timestamp in AssemblyInfo.Generated.cs for the Go CLI integration.

Change summary:

• 2026-02-15T03:12:06.6760225Z → 2026-03-15T03:13:32.2576653Z

Observation: The only change is the generation timestamp — no options classes were actually added, removed, or modified. This means the Go CLI tool's help output is unchanged since the last generation run (no new commands, flags, or descriptions were detected). This is expected and correct behavior from the generator.

No issues found. The change is safe, minimal, and correctly reflects a re-run of the options generator with no substantive differences in the Go CLI surface. Auto-merge with squash is appropriate here.

[claude]

Code Review

This automated PR updates the ModularPipelines.OptionsGenerator.GeneratedAt timestamp in AssemblyInfo.Generated.cs for the Go CLI integration.

Change summary:

• 2026-02-15T03:12:06.6760225Z → 2026-03-15T03:13:32.2576653Z

Observation: The only change is the generation timestamp — no options classes were actually added, removed, or modified. This means the Go CLI tool help output is unchanged since the last generation run (no new commands, flags, or descriptions were detected). This is expected and correct behavior from the generator.

No issues found. The change is safe, minimal, and correctly reflects a re-run of the options generator with no substantive differences in the Go CLI surface. Auto-merge with squash is appropriate here.

[claude]

Code Review

This automated PR updates the GeneratedAt timestamp in AssemblyInfo.Generated.cs for the Go CLI integration — and nothing else. The actual Go CLI options classes are unchanged, meaning the generator ran, detected no differences in the tool's help output, but still produced a PR purely because the timestamp changed.

This has happened repeatedly for this PR (based on prior review comments), and the same pattern is visible across at least 17 other open automated PRs. This is a systemic issue worth addressing.

---

Issue 1: The timestamp-only change bypass is not working

The workflow has a "Check for changes" step (.github/workflows/generate-cli-options.yml, line 535) that uses:

git diff --staged --quiet --ignore-all-space --ignore-blank-lines

The intent is to suppress no-op PRs, but --ignore-all-space and --ignore-blank-lines only ignore whitespace differences — they do not ignore a meaningful string change like a timestamp value update. The GeneratedAt timestamp changes on every run because it is set at generation time (DateTime.UtcNow or equivalent), so the diff is always non-empty even when zero functional content changed.

Recommended fix: Exclude AssemblyInfo.Generated.cs from the change-detection check, or check for changes only in the Options/, Services/, and Extensions/ subdirectories where actual functionality lives:

git add 'src/**/*.cs'
# Only count meaningful changes — ignore the timestamp file
if git diff --staged --quiet --ignore-all-space --ignore-blank-lines -- \
    ':(exclude)src/**/AssemblyInfo.Generated.cs'; then
  echo "has_changes=false" >> $GITHUB_OUTPUT

An alternative is to stop writing GeneratedAt at generation time and instead compute it only when there is at least one real change, or use the tool's own version string (e.g., go version output) as the metadata value rather than a wall-clock timestamp. A tool version is meaningful; a generation timestamp is not.

---

Issue 2: The timestamp serves no useful purpose in its current form

AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", ...) records when the generator last ran, not when the CLI tool's schema last changed. These are different things. The current value is noise: it increases diff churn, triggers spurious PRs, and provides no actionable information to a consumer of the library (who cares about the CLI tool version, not the timestamp of the last CI run).

Consider replacing it with the CLI tool's version string:

[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.ToolVersion", "go1.22.4")]

This would only change when the installed tool version actually changes, making the AssemblyInfo.Generated.cs file stable across re-runs of the same tool version — and therefore never the sole content of an automated PR.

---

Issue 3: PR accumulation at scale

There are currently 17+ open automated PRs, all from the same weekly scheduled run. If every tool produces a timestamp-only change, the repository ends up with O(n_tools) open PRs per week that each carry zero signal. This creates review overhead even with auto-merge enabled, since branch protection checks still need to pass and CI still needs to run for each.

A cleaner design would be to have the generator emit a single PR per weekly run that batches all truly changed tools together, skipping tools whose options classes did not change. The current per-tool matrix job is appropriate for parallelism, but the PR creation step should gate on real changes.

---

Summary

Concern	File	Recommendation
Timestamp bypasses change-detection logic	.github/workflows/generate-cli-options.yml:535	Exclude AssemblyInfo.Generated.cs from the diff check
GeneratedAt is always stale by definition	AssemblyInfo.Generated.cs pattern	Replace with tool version string
Spurious PRs accumulate across all tools	Workflow design	Gate PR creation on non-timestamp changes only

The PR itself is harmless to merge, but the underlying pattern will keep producing noise every week until the root cause in the workflow is fixed.

[claude]

Code Review (2026-03-29 run)

This PR again updates only the GeneratedAt timestamp in src/ModularPipelines.Go/AssemblyInfo.Generated.cs, from 2026-03-15T03:13:32.2576653Z to 2026-03-29T03:14:22.3953173Z. No Go CLI options classes were added, removed, or changed.

Previous review concerns — status

The prior review (2026-03-22) raised three systemic issues with the workflow that are still unaddressed:

1. Change-detection logic does not exclude the timestamp file. The --ignore-all-space/--ignore-blank-lines flags in the workflow's diff check do not suppress a string-value change like the timestamp. Every generator run produces a non-empty diff even when nothing functional changed, which is why this PR exists for the sixth consecutive week without any real content.

2. GeneratedAt records generator run time, not tool schema change time. Replacing it with the tool's own version string (e.g., go1.24.1) would make AssemblyInfo.Generated.cs stable across re-runs that install the same version, eliminating the spurious diff entirely.

3. PR accumulation at scale. Timestamp-only PRs are being opened for all tool integrations every week, each requiring CI to pass before auto-merge completes. This is avoidable noise.

None of these were addressed in the week since the last review. The PR is still safe to merge as-is, but the root cause in the workflow (generate-cli-options.yml) remains unfixed and will continue producing identical PRs weekly.

Recommendation: Before the next scheduled run, either exclude AssemblyInfo.Generated.cs from the diff gate or switch to a tool-version-based metadata attribute. This is a small workflow change with a high signal-to-noise payoff.

[claude]

Code Review (2026-04-05 run)

This PR again updates only the `GeneratedAt` timestamp in `src/ModularPipelines.Go/AssemblyInfo.Generated.cs`:

```diff
-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-02-15T03:12:06.6760225Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-05T03:15:26.0233120Z")]
```

No Go CLI options classes were added, removed, or changed. This is now the eighth consecutive weekly run to produce a timestamp-only PR with zero functional content.

Status of previous review concerns

Three systemic issues were raised in the 2026-03-22 review and re-raised in the 2026-03-29 review. As of this run, all three remain unaddressed:

1. Change-detection in the workflow does not filter out the timestamp file. The `--ignore-all-space` and `--ignore-blank-lines` flags used in the diff gate do not suppress a string-value change. The timestamp always changes, so the diff is always non-empty, and a PR is always opened — regardless of whether anything functional changed.

2. `GeneratedAt` records when the generator ran, not when the CLI tool changed. This is the wrong signal. A consumer of the library cares about the Go toolchain version, not the CI run timestamp. Replacing the attribute with the tool's own version string (e.g., `go1.24.x`) would make `AssemblyInfo.Generated.cs` stable across re-runs of the same installed version, eliminating the spurious diff entirely.

3. Weekly PR accumulation across all tool integrations. Each timestamp-only PR still occupies a CI slot, a PR queue entry, and a branch protection check before auto-merge resolves it. Over 8+ weeks and across all tool integrations this represents significant avoidable overhead.

Recommended fix (still the same)

The smallest effective change is to exclude `AssemblyInfo.Generated.cs` from the diff gate in `.github/workflows/generate-cli-options.yml`:

```bash
if git diff --staged --quiet --
':(exclude)src/**/AssemblyInfo.Generated.cs'; then
echo "has_changes=false" >> $GITHUB_OUTPUT
fi
```

A higher-value change is to replace the `GeneratedAt` wall-clock timestamp with the installed tool's version string, so the metadata is meaningful and stable:

```csharp
[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.ToolVersion", "go1.24.2")]
```

The PR is safe to merge as-is, but without fixing the root cause in the workflow these timestamp-only PRs will continue to be generated every week indefinitely.

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

[claude]

Code Review

This is an automated PR regenerating the Go CLI options, and the changes are clean. Here's my assessment:

What Changed

• Timestamp updated in AssemblyInfo.Generated.cs — routine and expected.
• #nullable enable added to all 7 generated Go files (Options + Services) — the substantive change.

Assessment: ✅ Good

#nullable enable addition is a positive improvement. Adding this directive to generated files makes nullable intent explicit and allows consumers to get compile-time null-safety guarantees when working with these types. This is consistent with the direction already taken in ModularPipelines.AmazonWebServices (which already has #nullable enable on its generated files).

One Architectural Observation

Many other packages (e.g., ModularPipelines.Azure) still lack #nullable enable on their generated files. This creates inconsistency across the suite — consumers of some packages get nullable annotations and others don't. This PR is not at fault (it's doing the right thing), but it highlights that the generator update should be propagated to all packages uniformly, not just on the next regeneration cycle.

Suggested follow-up (not a blocker): Consider triggering a regeneration pass across all packages once the generator emits #nullable enable, rather than waiting for each tool's CLI to change. A single "update all generated files" PR would eliminate the inconsistency sooner and reduce the window where nullable behavior differs between packages.

No blocking issues — this PR is good to merge.

[claude]

Code Review

This is an automated PR regenerating the Go CLI options, and the changes are clean. Here's my assessment:

What Changed

• Timestamp updated in AssemblyInfo.Generated.cs — routine and expected.
• #nullable enable added to all 7 generated Go files (Options + Services) — the substantive change.

Assessment: ✅ Good

#nullable enable addition is a positive improvement. Adding this directive to generated files makes nullable intent explicit and allows consumers to get compile-time null-safety guarantees when working with these types. This is consistent with the direction already taken in ModularPipelines.AmazonWebServices (which already has #nullable enable on its generated files).

One Architectural Observation

Many other packages (e.g., ModularPipelines.Azure) still lack #nullable enable on their generated files. This creates inconsistency across the suite — consumers of some packages get nullable annotations and others don't. This PR is not at fault (it's doing the right thing), but it highlights that the generator update should be propagated to all packages uniformly, not just on the next regeneration cycle.

Suggested follow-up (not a blocker): Consider triggering a regeneration pass across all packages once the generator emits #nullable enable, rather than waiting for each tool's CLI to change. A single 'update all generated files' PR would eliminate the inconsistency sooner and reduce the window where nullable behavior differs between packages.

No blocking issues — this PR is good to merge.