[Automated] Update newman CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to newman 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 minimal automated update PR — the sole change is a timestamp bump in .

What Changed

---

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-02-22T03:13:01.0642949Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:16:22.0239443Z")]

The generator re-ran and updated the timestamp, but found no actual changes to the newman CLI options — no new commands, no removed commands, no changed option types or descriptions.

Assessment

This PR is safe to merge as-is. The only change is the "GeneratedAt" timestamp, which is expected behaviour from the automated generator when the underlying CLI tool hasn't changed between runs. This confirms the generator is working correctly and newman's CLI interface remains stable.

Minor Observation

The PR description states "Added new commands if any were detected" and "Updated option types and descriptions", but the actual diff shows only the timestamp changed. The templated PR description can be slightly misleading for reviewers in cases like this where the CLI tool had no real changes. It would be clearer if the description dynamically reflected whether substantive options changes were detected (or explicitly noted "No option changes detected — timestamp updated only"). That said, this is a cosmetic issue with the PR template, not a code correctness concern.

Overall: LGTM. Safe to merge.

[claude]

Code Review

This is a minimal automated update PR — the sole change is a timestamp bump in AssemblyInfo.Generated.cs.

What Changed

The generator re-ran and updated the ModularPipelines.OptionsGenerator.GeneratedAt assembly metadata timestamp from 2026-02-22T03:13:01 to 2026-03-01T03:16:22, but found no actual changes to the newman CLI options — no new commands, no removed commands, no changed option types or descriptions.

Assessment

This PR is safe to merge as-is. The only change is the "GeneratedAt" timestamp, which is expected behaviour from the automated generator when the underlying CLI tool has not changed between runs. This confirms the generator is working correctly and newman's CLI interface remains stable.

Minor Observation

The PR description says "Added new commands if any were detected" and "Updated option types and descriptions", but the actual diff shows only the timestamp changed. The templated PR description can be slightly misleading for reviewers in cases like this where the CLI tool had no real changes. It would be clearer if the generator either skipped creating a PR entirely when no substantive changes are detected, or dynamically noted "No option changes detected — timestamp updated only" in the PR body. That said, this is a cosmetic issue with the PR template, not a code correctness concern.

Overall: LGTM. Safe to merge.

[claude]

Code Review

This is another minimal automated update PR, consistent with the pattern observed in previous reviews.

What Changed

src/ModularPipelines.Newman/AssemblyInfo.Generated.cs

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:16:22.0239443Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-08T03:09:07.7636125Z")]

Only the GeneratedAt timestamp changed — again no substantive changes to newman CLI options were detected.

Assessment

This PR is safe to merge. The timestamp bump confirms the generator ran successfully on 2026-03-08 and found newman's CLI interface unchanged from the previous run (2026-03-01). This is expected, routine behaviour.

Carried-Over Observation (Unaddressed)

Previous reviews flagged that the PR description template is slightly misleading when no actual option changes are detected — it still says "Added new commands if any were detected" and "Updated option types and descriptions". This remains unaddressed. While it's a cosmetic issue, it adds noise for reviewers trying to understand the real scope of the change. The generator could either:

• Skip opening a PR entirely when the only diff is the timestamp, or
• Dynamically set the PR body to indicate "No option changes detected — timestamp updated only"

This is a low-priority improvement but worth addressing to reduce reviewer confusion over time.

Overall: LGTM. Safe to merge.

[claude]

Code Review

This is the fourth consecutive automated PR for newman that contains only a timestamp bump — no actual CLI option changes were detected.

What Changed

src/ModularPipelines.Newman/AssemblyInfo.Generated.cs

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-08T03:09:07.7636125Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-15T03:13:31.7712539Z")]

Only the GeneratedAt timestamp changed. Newman's CLI interface remains unchanged.

Repeated Unaddressed Observation

Previous reviews on 2026-03-01 and 2026-03-08 both raised the same concern: the automated generator opens a PR even when the only diff is a timestamp update, producing reviewer noise and wasted CI cycles. This has now gone unaddressed across three review cycles.

The core issue is an architectural one in the generator workflow: the generator should compare the substantive generated content against the existing content before deciding whether to open a PR. A timestamp is not a meaningful change to the options API surface, and opening a PR solely for it provides no value.

Concrete options to address this:

1. Skip the PR entirely when the only delta is the GeneratedAt timestamp. The generator already knows what it generated — it can diff the options class files before invoking the PR-creation step.
2. Separate the timestamp from the versioned content — store it in a file that is explicitly excluded from PR-creation logic, so it does not trigger a PR on its own.
3. Gate PR creation on substantive changes — check git diff -- '*.Generated.cs' ':!*AssemblyInfo*' (or equivalent) and only create a PR if that diff is non-empty.

Any of these approaches would eliminate the recurring noise while still ensuring real option changes are surfaced promptly.

Assessment

Safe to merge as-is. Newman's CLI interface is stable. However, given this is the fourth identical review comment without action, it may be worth prioritising the generator improvement to avoid this becoming an indefinite weekly occurrence.

Overall: LGTM for merging, but the generator workflow improvement is now overdue.

[claude]

Code Review

This is the fifth consecutive automated PR for newman containing only a timestamp bump — no substantive CLI option changes were detected.

What Changed

src/ModularPipelines.Newman/AssemblyInfo.Generated.cs

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-15T03:13:31.7712539Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-22T03:12:44.1702691Z")]

Newman's CLI interface remains unchanged for the fifth week running.

---

Root Cause Analysis (Generator Workflow)

Previous reviews (four of them now) have flagged this recurring noise and proposed fixes. Having now read both the generator source and the workflow, I can pinpoint exactly where the fix belongs.

GeneratorUtils.GenerateAssemblyInfo (line 85 in tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/GeneratorUtils.cs) unconditionally writes DateTime.UtcNow every time the generator runs:

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

This means the AssemblyInfo.Generated.cs file is always dirtied on disk, regardless of whether any options classes changed.

generate-cli-options.yml lines 527–542 ("Check for changes") stages all src/**/*.cs files and then uses git diff --staged --quiet --ignore-all-space --ignore-blank-lines to gate PR creation. The timestamp change (2026-03-15… → 2026-03-22…) is a non-whitespace content change, so it passes the check and triggers a PR even though nothing meaningful changed.

The fix needs to happen in GeneratorUtils.GenerateAssemblyInfo, not in the workflow. The corrected approach is to read the existing GeneratedAt value from the file on disk before writing and only update it when the substantive generated content has changed. Alternatively, the simplest targeted fix is to exclude AssemblyInfo.Generated.cs from the change-detection diff in the workflow:

-git add 'src/**/*.cs'
+git add 'src/**/*.cs'

-if git diff --staged --quiet --ignore-all-space --ignore-blank-lines; then
+# Exclude AssemblyInfo timestamp-only changes from the meaningful-change check
+if git diff --staged --quiet --ignore-all-space --ignore-blank-lines -- ':!src/**/AssemblyInfo.Generated.cs'; then

However this approach still stages and commits the timestamp file even when it is the only change, which wastes the PR. The cleaner fix at the generator level is to preserve the existing GeneratedAt value when no other generated files changed:

1. Before writing AssemblyInfo.Generated.cs, compare the hash of all other generated file contents against what is already on disk.
2. Only call DateTime.UtcNow when at least one options/service/enum file actually changed.

This eliminates the PR entirely for no-op runs rather than just hiding it behind a workflow filter.

Why This Matters

Each timestamp-only PR:

• Consumes a GitHub Actions run (all the tool-install steps, the dotnet build verification, etc.)
• Creates reviewer noise
• Occupies an auto-merge queue slot

With 40+ tools in the matrix running weekly, the aggregate waste from timestamp-only PRs across all stable tools is non-trivial. The pattern will continue indefinitely unless the generator is corrected, because no CLI tool changes weekly with the regularity implied by the current PR cadence.

Assessment

Safe to merge as-is. Newman's CLI interface is stable and this PR introduces no risk.

Overall: LGTM for merging. The generator-level fix for GeneratorUtils.GenerateAssemblyInfo is now overdue — this is the fifth review raising the same concern.

[claude]

Code Review

This is the sixth consecutive automated PR for newman containing only a timestamp bump — no substantive CLI option changes were detected.

What Changed

src/ModularPipelines.Newman/AssemblyInfo.Generated.cs

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-22T03:12:44.1702691Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-29T03:23:31.8876807Z")]

Newman's CLI interface remains unchanged for the sixth week running.

---

Unaddressed Concern — Now Six Reviews Deep

Five previous review cycles have flagged the same root cause and proposed fixes. The issue remains unaddressed. To be direct about where the fix belongs:

GeneratorUtils.GenerateAssemblyInfo (line 85) unconditionally stamps DateTime.UtcNow every run:

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

This always dirties AssemblyInfo.Generated.cs on disk, which passes the workflow's git diff --staged --quiet check and triggers a PR even when no options class content changed.

The recommended fix — preserve the existing GeneratedAt value when no other generated content has changed:

public static string GenerateAssemblyInfo(string targetNamespace, string toolName, string? existingGeneratedAt = null)
{
    var sb = new StringBuilder();
    // ... header ...
    sb.AppendLine($"[assembly: AssemblyMetadata(\"ModularPipelines.OptionsGenerator.Tool\", \"{toolName}\")]");
    // Only refresh the timestamp when caller explicitly passes null (i.e., when substantive changes were detected)
    var timestamp = existingGeneratedAt ?? DateTime.UtcNow.ToString("O");
    sb.AppendLine($"[assembly: AssemblyMetadata(\"ModularPipelines.OptionsGenerator.GeneratedAt\", \"{timestamp}\")]");
    return sb.ToString();
}

The orchestrator would then:

1. Generate all options/service/enum files.
2. Compare their content against what is on disk.
3. If no substantive files changed, read the existing GeneratedAt from AssemblyInfo.Generated.cs and pass it in — so the file is written identically and produces no git diff.
4. Only write a fresh timestamp when at least one options file actually changed.

This eliminates the PR entirely for no-op runs rather than just masking it. It also means the GeneratedAt timestamp accurately reflects the last time options actually changed, which is more semantically meaningful.

An alternative, simpler stopgap in the workflow would be to exclude AssemblyInfo.Generated.cs from the change-detection check:

-if git diff --staged --quiet --ignore-all-space --ignore-blank-lines; then
+if git diff --staged --quiet --ignore-all-space --ignore-blank-lines -- ':!src/**/AssemblyInfo.Generated.cs'; then

However this still stages and commits the timestamp file unnecessarily, so fixing it at the generator level is the cleaner solution.

Assessment

Safe to merge as-is. Newman's CLI interface is stable and this PR introduces no risk.

Overall: LGTM for merging. The generator-level fix is now six reviews overdue — it would eliminate this entire category of noise PRs across all stable tools in the matrix.

[claude]

Code Review

This is the seventh consecutive automated PR for newman containing only a timestamp bump — no substantive CLI option changes were detected.

What Changed

src/ModularPipelines.Newman/AssemblyInfo.Generated.cs

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-29T03:23:31.8876807Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-05T03:31:33.5042481Z")]

Newman's CLI interface remains unchanged for the seventh week running.

---

Root Cause — Still Unaddressed After Six Previous Reviews

Six prior review cycles have identified and precisely located the fix. The root cause remains in the generator source code:

tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/GeneratorUtils.cs, line 85:

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

This unconditionally stamps a fresh DateTime.UtcNow every run. WriteAssemblyInfoAsync in CodeGeneratorOrchestrator.cs calls GeneratorUtils.GenerateAssemblyInfo without comparing the new content to the existing file on disk. The AssemblyInfo.Generated.cs file is therefore always dirtied, always passes git diff --staged --quiet, and always triggers a PR — even when no options class content changed.

The Fix (same as previous reviews, now seven cycles overdue)

The cleanest solution is to make WriteAssemblyInfoAsync idempotent when no substantive changes occurred. The simplest targeted change in CodeGeneratorOrchestrator.cs:

private static async Task WriteAssemblyInfoAsync(
    string outputDirectory,
    CliToolDefinition toolDefinition,
    CancellationToken cancellationToken)
{
    var path = Path.Combine(outputDirectory, toolDefinition.OutputDirectory, "AssemblyInfo.Generated.cs");
    var newContent = GeneratorUtils.GenerateAssemblyInfo(toolDefinition.TargetNamespace, toolDefinition.ToolName);

    // Only write (and dirty git) when the content actually changed beyond the timestamp line
    if (File.Exists(path))
    {
        var existing = await File.ReadAllTextAsync(path, cancellationToken);
        var existingWithoutTimestamp = StripTimestamp(existing);
        var newWithoutTimestamp = StripTimestamp(newContent);
        if (existingWithoutTimestamp == newWithoutTimestamp)
        {
            // No substantive change — preserve the existing file (and its timestamp) unchanged
            return;
        }
    }

    await WriteFileAsync(path, newContent, cancellationToken);
}

private static string StripTimestamp(string content)
{
    // Remove the GeneratedAt line for comparison purposes
    return Regex.Replace(content,
        @"\[assembly: AssemblyMetadata\(""ModularPipelines\.OptionsGenerator\.GeneratedAt"", ""[^""]*""\)\]\r?\n",
        string.Empty);
}

Why this approach is better than the workflow-level workaround:

• It eliminates the PR entirely for no-op runs rather than just hiding it from the change-detection check.
• The GeneratedAt timestamp accurately reflects the last time options actually changed, which is more semantically meaningful.
• It fixes the problem at the source rather than papering over it in CI.

With 40+ tools in the matrix running weekly, the aggregate waste from timestamp-only PRs across all stable tools is non-trivial and will continue indefinitely without this fix.

Assessment

Safe to merge as-is. Newman's CLI interface is stable and this PR introduces no risk.

Overall: LGTM for merging. The generator-level fix is now seven reviews overdue.

[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 the eighth consecutive automated PR for newman containing only a timestamp bump — no substantive CLI option changes were detected.

What Changed

src/ModularPipelines.Newman/AssemblyInfo.Generated.cs

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-05T03:31:33.5042481Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-12T03:29:08.8744440Z")]

Newman's CLI interface remains unchanged for the eighth week running.

---

Root Cause — Unaddressed After Seven Previous Reviews

The fix has been documented in detail across seven prior reviews. In the interest of brevity, the short version:

tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/GeneratorUtils.cs, line 85 unconditionally writes DateTime.UtcNow on every run. This always dirties AssemblyInfo.Generated.cs, always passes the workflow's git diff --staged --quiet gate, and always triggers a PR — regardless of whether any options class content changed.

The fix (same as the last seven reviews): make WriteAssemblyInfoAsync in CodeGeneratorOrchestrator.cs idempotent by skipping the file write when the content is identical beyond the timestamp line. The exact code snippet was provided in the review for PR #2421 (seven reviews ago) and has not changed. This would eliminate the PR entirely for no-op runs, and also make the GeneratedAt timestamp semantically accurate (reflecting when options actually changed, not when the generator last ran).

At 40+ tools in the matrix running weekly, timestamp-only PRs across all stable tools represent a persistent, growing source of CI and reviewer noise that will not resolve itself.

Assessment

Safe to merge as-is. Newman's CLI interface is stable and this PR introduces no risk.

Overall: LGTM for merging. The generator-level fix is now eight reviews overdue.

[claude]

Code Review

This is the ninth automated update PR for newman — but unlike the previous eight, this one contains a substantive change in addition to the timestamp bump.

What Changed

AssemblyInfo.Generated.cs — Timestamp updated from 2026-04-12 to 2026-04-19 (routine).

5 generated files — #nullable enable added at the top of each:

• Options/NewmanOptions.Generated.cs
• Options/NewmanRunOptions.Generated.cs
• Options/NewmanUrlOptions.Generated.cs
• Services/INewman.Generated.cs
• Services/Newman.Generated.cs

---

Assessment of the #nullable enable Change

This is a positive, meaningful improvement. Adding #nullable enable to generated files:

• Brings them in line with modern C# nullable reference type (NRT) practices
• Allows the compiler to perform nullability flow analysis on these types, catching potential null dereference bugs at compile time
• Makes the generated API surface more expressive — callers can now see from signatures whether return types or parameters can be null

This is the first substantive change in nine consecutive PRs, which is good to see. It also implicitly addresses the previous concern: the generator now produces a real change (the NRT directive), so the PR is justified this time.

One Observation

The previous eight reviews consistently flagged that the generator opens PRs for timestamp-only changes, proposing a fix in GeneratorUtils.GenerateAssemblyInfo. That concern is implicitly resolved here by the presence of the #nullable enable change — this PR is legitimate. However, the underlying generator behaviour (unconditionally stamping DateTime.UtcNow regardless of substantive changes) is presumably still in place. If newman's CLI interface stabilises again, the same weekly timestamp-only PR cycle will resume. The generator-level fix proposed in previous reviews remains worth implementing to prevent that.

Conclusion

The #nullable enable addition is clean, consistent across all generated files, and correctly placed (after the <auto-generated> header comment block, before using directives). No issues found.

Overall: LGTM. Safe to merge.