[Automated] Update flyway CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to flyway 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 only change is a timestamp bump in AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:14:14.2808687Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-08T03:10:47.5741980Z")]

Assessment: ✅ No issues found

The change is exactly what is expected for a scheduled automated flyway CLI options regeneration run. The generated timestamp correctly reflects the new run date (2026-03-08), and there are no changes to the actual options classes themselves — meaning the latest flyway CLI help output matches the existing generated code.

A few observations for general awareness:

1. No options drift detected: The fact that only the timestamp changed (and no options classes were modified) is a good signal — the flyway CLI interface hasn't changed since the last generation run on 2026-03-01. This is healthy.

2. Automation is working correctly: The PR was opened automatically, the solution built successfully, and auto-merge is enabled — the pipeline is functioning as intended.

3. Timestamp-only PRs could be suppressed: As a minor architectural suggestion (not a blocker), the generator could optionally skip opening a PR when only the timestamp changes and no actual option definitions differ. This would reduce noise in the PR list. This is purely a quality-of-life improvement and not a correctness concern.

This PR is safe to merge as-is.

[claude]

Code Review

Change Summary

This PR contains a single-line change in src/ModularPipelines.Flyway/AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-01T03:14:14.2808687Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-15T03:15:23.2673415Z")]

Assessment: No issues found

This is a routine automated regeneration run. Only the GeneratedAt timestamp was updated — no options classes, enums, service interfaces, or implementation files changed. This is the expected outcome when the flyway CLI's help output is identical to the previously scraped version.

Observations

No CLI interface drift: The absence of any changes beyond the timestamp confirms that flyway's CLI has not introduced new commands, removed options, or changed flag names since the 2026-03-01 run. This is a healthy signal and validates that the automation is correctly detecting a stable interface.

Automation is functioning correctly: The generator ran, compared output, produced an identical options snapshot, updated the timestamp, opened this PR, verified the build, and enabled auto-merge — the full pipeline is operating as designed.

Minor improvement opportunity (non-blocking): With 30+ tool packages each running on a schedule, timestamp-only PRs like this one will accumulate regularly. The generator could be extended to skip PR creation when the only diff is the GeneratedAt metadata value. This would reduce noise without losing any safety guarantees, since a timestamp-only change carries no semantic information for consumers of the library. This is purely a quality-of-life consideration for repository maintainers.

This PR is safe to merge as-is.

[claude]

Code Review

This is a minimal automated update — just a timestamp bump in AssemblyInfo.Generated.cs reflecting when the options generator last scraped the Flyway CLI help output.

Change Summary

• File: src/ModularPipelines.Flyway/AssemblyInfo.Generated.cs
• Change: GeneratedAt metadata updated from 2026-03-01T03:14:14Z → 2026-03-22T03:15:39Z

Assessment: ✅ LGTM

The change is exactly what it should be — an auto-generated timestamp update with no behavioral impact. The AssemblyMetadata attribute is purely informational, used to track when the generator last ran against the installed Flyway CLI.

No issues found. The automated pipeline is working as intended.

[claude]

Code Review

This PR continues the weekly automated Flyway CLI options regeneration cadence. The only change is a timestamp bump in src/ModularPipelines.Flyway/AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-22T03:15:39Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-29T03:16:21Z")]

Assessment: LGTM

The change is correct and expected. No options classes, enums, or service interfaces were modified, confirming that the Flyway CLI interface is stable and unchanged since last week's run.

Follow-up on Previous Suggestion

Previous reviews (2026-03-08, 2026-03-15, 2026-03-22) have repeatedly flagged the same improvement opportunity: skip PR creation when the only diff is the GeneratedAt timestamp. This PR is now at least the fourth consecutive week where only the timestamp changed. The suggestion remains unaddressed and is worth revisiting — at this point it is generating weekly no-op PRs that require review bandwidth.

The concrete approach would be to add a pre-PR-creation check in the generator or the CI workflow that computes a diff excluding the GeneratedAt line, and suppresses the PR if that filtered diff is empty. This is a low-effort change with a meaningful reduction in noise across all 30+ tool packages that run on this schedule.

This PR is safe to merge as-is.

[claude]

Code Review

This PR is the latest in a series of weekly automated Flyway CLI options regeneration runs. The only change is a timestamp update in `src/ModularPipelines.Flyway/AssemblyInfo.Generated.cs`:

```diff
-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-03-29T03:16:21Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-05T03:15:49Z")]
```

Assessment: LGTM

The change is correct and has no behavioral impact. No options classes, enums, service interfaces, or implementation files changed, confirming the Flyway CLI interface remains stable.

Recurring Observation (5th consecutive week)

Previous reviews on 2026-03-08, 2026-03-15, 2026-03-22, and 2026-03-29 all flagged the same improvement opportunity: skip PR creation when the only diff is the `GeneratedAt` timestamp. This is now the fifth week in a row with a no-op PR.

This suggestion remains unaddressed. The accumulated cost is real — each of these PRs requires review bandwidth (even if automated), consumes CI minutes, and contributes noise to the repository's PR list. Given that there are 30+ tool packages on this schedule, the total volume of timestamp-only PRs can be significant.

A concrete fix: in the generator workflow, after generating the files, compute a diff that excludes the `GeneratedAt` line (e.g., `git diff -- . | grep -v GeneratedAt`). If that filtered diff is empty, skip the PR entirely. The timestamp will be updated on the next run that does produce real changes, so no tracking information is lost.

This PR is safe to merge as-is.

[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

Change Summary

This PR updates a single line in src/ModularPipelines.Flyway/AssemblyInfo.Generated.cs:

-[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-05T03:15:49.Z")]
+[assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-12T03:16:59.8894483Z")]

No options classes, enums, service interfaces, or implementation files changed. The Flyway CLI interface is stable.

---

Previous Review Comments — Status

Previous reviews (2026-03-08, 2026-03-15, 2026-03-22, 2026-03-29, 2026-04-05) have all raised the same suggestion: skip PR creation when the only diff is the GeneratedAt timestamp. This is now the sixth consecutive week with a no-op PR, and the suggestion remains unaddressed.

---

Root Cause Analysis

I traced through the workflow and the generator code to understand why this keeps happening.

In the workflow (generate-cli-options.yml, lines 527–542):

- name: Check for changes
  id: changes
  run: |
    git add 'src/**/*.cs'
    if git diff --staged --quiet --ignore-all-space --ignore-blank-lines; then
      echo "has_changes=false" >> $GITHUB_OUTPUT
    else
      echo "has_changes=true" >> $GITHUB_OUTPUT
    fi

The --ignore-all-space and --ignore-blank-lines flags suppress whitespace-only changes — but the timestamp change is not whitespace. It is a content change on a non-blank line, so git diff --staged --quiet exits non-zero and has_changes=true is set correctly by git's perspective. The guard works as designed — the problem is that it doesn't know the timestamp is semantically meaningless.

In the generator (GeneratorUtils.cs, line 85):

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

DateTime.UtcNow is always different on each run, so AssemblyInfo.Generated.cs always changes, even when nothing else does.

---

Recommended Fix

There are two complementary approaches. Pick either one; using both together provides belt-and-suspenders coverage.

Option A: Fix in the workflow (no C# changes needed)

After staging, filter out the AssemblyInfo.Generated.cs file before checking for meaningful changes:

- name: Check for changes
  id: changes
  run: |
    git add 'src/**/*.cs'

    # Check whether anything changed *excluding* the timestamp-only AssemblyInfo files
    MEANINGFUL_DIFF=$(git diff --staged --name-only | grep -v 'AssemblyInfo\.Generated\.cs' || true)

    if [ -z "$MEANINGFUL_DIFF" ]; then
      echo "has_changes=false" >> $GITHUB_OUTPUT
      echo "No meaningful changes detected for ${{ matrix.tool }} (only timestamp updated)"
    else
      echo "has_changes=true" >> $GITHUB_OUTPUT
      echo "Changed files:"
      echo "$MEANINGFUL_DIFF"
    fi

This is a two-line change to the existing bash block and requires no changes to the generator or any C# code.

Option B: Fix in the generator (more robust, handles all future tools)

In GeneratorUtils.GenerateAssemblyInfo, read the existing file first and preserve the GeneratedAt timestamp if the substantive content (options, commands, enums) has not changed. Alternatively, omit the GeneratedAt field entirely when the generator detects no content changes — or write it only once and leave it stable until a real change occurs.

A simpler variant: pass a generatedAt parameter to GenerateAssemblyInfo so the caller can supply the existing timestamp when no meaningful changes were detected:

public static string GenerateAssemblyInfo(string targetNamespace, string toolName, DateTimeOffset? generatedAt = null)
{
    var timestamp = (generatedAt ?? DateTimeOffset.UtcNow).ToString("O");
    // ...
    sb.AppendLine($"[assembly: AssemblyMetadata(\"ModularPipelines.OptionsGenerator.GeneratedAt\", \"{timestamp}\")]");
}

Then in WriteAssemblyInfoAsync, read the existing timestamp from the file if it exists and the generated content is unchanged.

---

Impact Assessment

With 30+ tool packages running weekly, this pattern produces up to ~30 no-op PRs per week across the repository. Over a year that is 1,500+ PRs that carry no information. Option A above is a ~5-line change to the workflow YAML and fully eliminates the noise without any risk to correctness — the AssemblyInfo timestamp will still be updated whenever a real change is present (because the PR will be created and include the updated timestamp).

This PR is safe to merge as-is, but the underlying issue is now six weeks overdue for a fix.

[claude]

Code Review

This is a clean automated PR regenerating the Flyway CLI options package. The changes are minimal and intentional.

What Changed

• Regeneration timestamp updated in
• added to the top of all 16 generated files (options + service classes)

Observation: Redundant but Idiomatic

The directive is technically redundant — already sets <Nullable>enable</Nullable> globally, so nullable reference types are already enabled project-wide. However, adding the explicit directive to generated files is a well-established pattern for a good reason: it makes each generated file self-describing and compilable in isolation, even if copied into a project that doesn't have the global setting. This is the right call for generated code.

Consistency Note

Other tool packages (e.g., ModularPipelines.Google) don't yet have #nullable enable in their generated files, suggesting the generator template was updated and Flyway is the first tool to be regenerated with it. This is expected behavior for a rolling rollout — other packages will pick this up on their next regeneration cycle.

Verdict

No issues. The changes are correct, idiomatic, and safe. The incremental rollout of the #nullable enable generator improvement via per-tool regeneration PRs is a clean approach.

[claude]

Code Review

This is a clean automated PR regenerating the Flyway CLI options package. The changes are minimal and intentional.

What Changed

• Regeneration timestamp updated in AssemblyInfo.Generated.cs
• #nullable enable added to the top of all 16 generated files (options + service classes)

Observation: Redundant but Idiomatic

The #nullable enable directive is technically redundant - Directory.Build.props already sets Nullable=enable globally, so nullable reference types are already enabled project-wide. However, adding the explicit directive to generated files is a well-established pattern for a good reason: it makes each generated file self-describing and compilable in isolation, even if copied into a project without the global setting. This is the right call for generated code.

Consistency Note

Other tool packages (e.g., ModularPipelines.Google) do not yet have #nullable enable in their generated files, suggesting the generator template was updated and Flyway is the first tool to be regenerated with it. This is expected behavior for a rolling rollout - other packages will pick this up on their next regeneration cycle.

Verdict

No issues. The changes are correct, idiomatic, and safe. The incremental rollout of the #nullable enable generator improvement via per-tool regeneration PRs is a clean approach.