[Automated] Update docker CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to docker 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: [Automated] Update docker CLI Options

This is an auto-generated PR, so all observations relate to the generator's output quality rather than manual coding decisions.

---

Summary

The changes faithfully reflect the current Docker CLI scraped at 2026-03-01T03:12:33Z. The update is structurally sound and the new DockerTrust command group is a welcome addition.

---

Observations

Breaking Changes (worth calling out in release notes)

Several changes silently break existing consumer code:

1. --no-pause → --pause in DockerCommitOptions and DockerContainerCommitOptions: The semantics are inverted — code that set NoPause = true to skip pausing will now have no effect, and the new Pause property defaults to null (which Docker treats as pause). Any automation relying on the old option will silently change behavior.

2. DockerImageLoadOptions.Platform: Changed from IEnumerable<string>? to string?. Any code passing multiple platforms will break at compile time, which is fine — but the Docker docs actually still support comma-separated platforms via this flag in some versions. Worth a closer look at whether the generator's source CLI version is accurate here.

3. Bake() / DockerBakeOptions removed: The entire docker bake command has been dropped from the interface and implementation. This is a significant removal — docker bake is a BuildKit feature that still ships with Docker. Was it removed from docker --help output on the specific version being scraped? If so, it may be a tooling version difference rather than a genuine API removal.

Truncated XML Summary

In DockerTrustSignerRemoveOptions.Generated.cs:

/// <summary>
/// Do not prompt for confirmation before removing the most
/// </summary>

The summary is truncated — the Docker CLI help likely says something like "...removing the most recently added signer". The generator appears to be cutting off XML doc comments mid-sentence. This is a generator-level bug worth fixing so docs render correctly in IDE tooltips.

Lazy Sub-Service Initialization Not Using DI

In DockerTrust.Generated.cs:

private DockerTrustKey _key;
private DockerTrustSigner _signer;

public DockerTrustKey Key => _key ??= new DockerTrustKey(_command);
public DockerTrustSigner Signer => _signer ??= new DockerTrustSigner(_command);

DockerTrustKey and DockerTrustSigner are created with new rather than injected via DI. This means they cannot be mocked or overridden independently in tests. Compare this to how DockerSwarm, DockerSystem etc. are all resolved through DI (registered in DockerExtensions.Generated.cs). The sub-services under DockerTrust are not registered in DI, making them inconsistent with the rest of the generated service hierarchy.

If this is an intentional pattern for "nested" command groups, the generator should document this distinction. If it's unintentional, the sub-services should also be DI-registered.

--kernel-memory is Deprecated

--kernel-memory was deprecated in Docker Engine v20.10 (2020) after kernel memory accounting was removed from the Linux cgroup v1 implementation. Adding it back to DockerContainerRunOptions, DockerContainerCreateOptions, and DockerCreateOptions will cause a Docker warning or no-op on most modern systems. The generator may be scraping from an older Docker CLI version or one that still shows the flag in help output even though it's deprecated.

---

What's Good

• The new DockerTrust command hierarchy (DockerTrust, DockerTrustKey, DockerTrustSigner) is well-structured and mirrors the actual CLI command tree cleanly.
• DockerPlugin.Push() is a useful new addition.
• Docs on DockerComposeBuildOptions.Quiet updated from "Suppress the build output" to "Don't print anything to STDOUT" — more accurate.
• Removal of --use-api-socket and several stale Compose options keeps the API surface clean.

---

Recommendations

The most impactful improvement would be in the generator itself:

1. Add truncation detection/warning for XML doc comments
2. Consider flagging deprecated CLI options in the generated output (e.g., [Obsolete] attribute)
3. Ensure consistent DI registration depth for nested service groups

[claude]

Code Review: [Automated] Update docker CLI Options (Re-generation 2026-03-08)

This review compares the current state of the PR (generated 2026-03-08) against the previous review posted 2026-03-01.

---

Status of Previous Review Items

All items raised in the prior review remain unaddressed in this re-generated version. Since these are generator-level concerns, the fixes need to happen in tools/ModularPipelines.OptionsGenerator/ before they will appear in future automated PRs.

---

1. Truncated XML Doc Comment — Still Present

In DockerTrustSignerRemoveOptions.Generated.cs the doc comment is still cut off:

/// <summary>
/// Do not prompt for confirmation before removing the most
/// </summary>

The Docker CLI help for --force reads: "Do not prompt for confirmation before removing the most recently added signer". The generator is truncating at a word boundary. This renders poorly in IDE tooltips. The generator's XML doc sanitisation/truncation logic needs a fix.

---

2. Lazy Sub-Service Initialization Inconsistent with DI — Still Present

DockerTrust.Generated.cs still creates sub-services with new:

private DockerTrustKey _key;
private DockerTrustSigner _signer;

public DockerTrustKey Key => _key ??= new DockerTrustKey(_command);
public DockerTrustSigner Signer => _signer ??= new DockerTrustSigner(_command);

Compare to how DockerSwarm, DockerSystem, DockerPlugin, DockerVolume etc. are all injected through DI and registered in DockerExtensions.Generated.cs. The DockerTrustKey and DockerTrustSigner sub-services are not registered in DI and cannot be independently mocked in tests.

If the intent is a lazy-nested pattern for command groups, this is an architectural inconsistency the generator should resolve uniformly — either all nested sub-services use lazy-new or all use DI injection and registration.

---

3. --no-pause → --pause Semantic Inversion — Still a Breaking Change

DockerCommitOptions and DockerContainerCommitOptions changed from NoPause to Pause (with default true). This inverts the semantics silently — existing consumer code setting NoPause = true will now produce the opposite behavior. This warrants at minimum a changelog entry, and ideally a [Obsolete] shim property in a non-generated extension file to ease migration.

---

4. --kernel-memory — Deprecated Flag Re-introduced

The --kernel-memory option has been re-added to DockerContainerRunOptions, DockerContainerCreateOptions, DockerCreateOptions, and DockerRunOptions. This flag was deprecated in Docker Engine v20.10 and is a no-op on cgroup v2 hosts. The generator should emit [Obsolete("--kernel-memory was deprecated in Docker Engine 20.10 and has no effect on cgroup v2 hosts.")] for known-deprecated flags, or suppress them from output entirely.

---

What's Good

• The DockerTrust command hierarchy (Trust, TrustKey, TrustSigner) is a welcome and well-structured addition that mirrors the Docker CLI tree correctly.
• DockerPlugin.Push() is a useful new method.
• Removal of stale Compose options (--since/--until from events, --no-tty from exec, --quiet-build from up) keeps the surface clean.
• The --disable-content-trust flag is consistently added across all relevant commands (pull, push, create, run, plugin install/upgrade).

---

Generator Recommendations (Unchanged from Previous Review)

These are the underlying fixes that would prevent these issues from recurring in future automated PRs:

1. Fix XML doc truncation — detect and preserve complete sentences from CLI help output
2. Emit [Obsolete] for known-deprecated flags — cross-reference against Docker deprecation notices or a maintained list
3. Unify DI registration depth — either register all sub-service command groups through DI (preferred for testability) or document the intentional inconsistency

[claude]

Code Review

This is an automated update to Docker CLI options generated by ModularPipelines.OptionsGenerator. The changes look broadly correct and consistent with the established pattern. A few observations:

Good

• The new DockerTrust service group is well-structured, following the same pattern as other Docker service groups (DockerPlugin, DockerSwarm, DockerSystem, etc.)
• Registration in DockerExtensions.Generated.cs and constructor injection in Docker.Generated.cs are properly wired up
• The IDocker interface is kept in sync

---

Potential Issues

1. Breaking change: DockerCommitOptions — NoPause → Pause

-[CliFlag("--no-pause")]
-public bool? NoPause { get; set; }
+[CliFlag("--pause", ShortForm = "-p")]
+public bool? Pause { get; set; }

This is a breaking change with inverted semantics. Any caller previously using NoPause = true to skip pausing must now use Pause = false. Depending on the Docker CLI version that drove this change, it may also reflect a genuine CLI flag rename — but if so, both old and new consumers will be affected without a deprecation notice.

Worth considering whether a deprecation shim (keeping NoPause with an [Obsolete] attribute pointing to Pause) should be added before removing it, at least for a version cycle.

---

2. Lazy initialization in DockerTrust is inconsistent with DI usage elsewhere

In DockerTrust.Generated.cs:

private DockerTrustKey _key;
private DockerTrustSigner _signer;

public DockerTrustKey Key => _key ??= new DockerTrustKey(_command);
public DockerTrustSigner Signer => _signer ??= new DockerTrustSigner(_command);

Other service groups (e.g., Docker.Generated.cs) receive sub-services via constructor injection from DI. DockerTrust creates its sub-services via new in lazy properties, bypassing DI. This means:

• DockerTrustKey and DockerTrustSigner cannot have their own scoped dependencies injected
• The pattern diverges from the rest of the codebase

If the generator is producing this pattern for nested sub-groups (two levels deep), it may be worth updating the generator to either register these in DI or pass them in via constructor injection (as Docker does with DockerPlugin, DockerSwarm, etc.).

---

3. Truncated XML doc comment

In DockerTrustSignerRemoveOptions.Generated.cs:

/// <summary>
/// Do not prompt for confirmation before removing the most
/// </summary>

The description is clearly truncated — "removing the most" is an incomplete sentence. This suggests the generator's CLI help scraper is cutting off the description. The full description is likely "...before removing the most recent signer" or similar. Worth investigating whether the generator has a line-length truncation bug.

---

4. Removed options may be breaking for existing users

Several options were removed that may still be in use:

• DockerComposeEventsOptions: --since / --until (useful time-filtering options)
• DockerComposeExecOptions: --no-tty / -T
• DockerComposeBuildOptions: --provenance, --sbom

If these were removed because the Docker CLI no longer supports them, that's fine. But if they were dropped due to a version mismatch during generation (e.g., using an older Docker version on the build agent), they'd silently disappear from the API.

---

Summary

The overall structure is clean and follows established conventions. The main concern worth acting on is issue #2 (DI inconsistency for DockerTrustKey/DockerTrustSigner) — this is a generator-level issue that could cause subtle problems if those sub-services ever need injected dependencies. The breaking NoPause → Pause change (#1) is also worth a second look before merge.

[claude]

Code Review: [Automated] Update docker CLI Options

This is a follow-up automated update (scraped 2026-03-22) to the one previously reviewed. All observations relate to the generator's output quality.

---

Previous Issues — Status Check

Two issues flagged in the prior review remain unaddressed:

1. Truncated XML doc comment — still present

In DockerTrustSignerRemoveOptions.Generated.cs (line added this PR):

/// <summary>
/// Do not prompt for confirmation before removing the most
/// </summary>

The sentence is still cut off mid-thought. The Docker CLI help likely says something like "...removing the most recently added signer". This is a generator-level bug where the scraper is truncating at a line-length boundary. It renders broken tooltips in IDEs and generates malformed XML docs. The generator should either handle multi-line help text or strip at a sentence boundary.

2. Sub-services under DockerTrust bypassing DI — still present

DockerTrustKey and DockerTrustSigner are lazily instantiated with new inside DockerTrust:

public DockerTrustKey Key => _key ??= new DockerTrustKey(_command);
public DockerTrustSigner Signer => _signer ??= new DockerTrustSigner(_command);

Meanwhile DockerSwarm, DockerSystem, DockerVolume, etc. are all registered with services.TryAddScoped<T>() and injected through the constructor. The DockerTrust sub-services are not registered in DockerExtensions.Generated.cs, making them impossible to mock in unit tests and inconsistent with the rest of the service hierarchy.

Either the nested sub-services should also be DI-registered and constructor-injected, or the generator should document the intentional distinction.

---

New Observations This PR

Timeout typed as string? across all builder options

All seven builder command options classes now have:

[CliOption("--timeout", Format = OptionFormat.EqualsSeparated)]
public string? Timeout { get; set; }

Docker's --timeout accepts a duration string (e.g., "20s", "1m30s"). Using string? is the generator's safe default, but it sacrifices type safety and discoverability. TimeSpan? with a custom serializer or a Duration value object would be more expressive and consistent with how .NET APIs typically model time values. At minimum, the XML doc comment should show the expected format (it currently only says "default 20s", which is preserved from the CLI help).

This is a generator-level architectural decision worth revisiting — it affects all duration options across the codebase, not just Timeout.

DockerBakeOptions / Bake() removal

Previously flagged: the entire docker bake command was removed. This PR carries that removal forward. docker bake is a BuildKit command and still widely used — its removal from the scraped CLI help likely reflects a version difference (e.g., docker without BuildKit context installed). This is a silent breaking change for existing users. Worth a changelog note or a semver bump consideration.

---

What's Good

• New DockerTrust hierarchy (DockerTrust, DockerTrustKey, DockerTrustSigner) is complete and well-structured, mirroring the actual docker trust CLI tree.
• DockerPlugin.Push() is a useful addition.
• --timeout is consistently added across all relevant builder subcommands (create, du, inspect, ls, prune, rm) — good coverage.
• DockerBuilderImagetoolsCreateOptions.MetadataFile is a useful new option.
• The generator timestamp metadata in AssemblyInfo.Generated.cs is a nice traceability feature.

[claude]

Code Review: [Automated] Update docker CLI Options (2026-03-29)

This review checks the latest re-generation against all issues raised in prior reviews (2026-03-01, 2026-03-08, 2026-03-15, 2026-03-22).

---

Status of Previously Raised Issues

Issue 1: Truncated XML doc comment — STILL UNRESOLVED

In DockerTrustSignerRemoveOptions.Generated.cs the doc comment for --force continues to be truncated:

/// <summary>
/// Do not prompt for confirmation before removing the most
/// </summary>

This has been flagged in every review since 2026-03-01. The Docker CLI help reads: "Do not prompt for confirmation before removing the most recently added signer". The generator is truncating at a line-length boundary. This needs a fix in the generator's CLI help text parsing logic — the scraper should read complete sentences rather than cutting at a fixed column width.

Issue 2: DockerTrustKey and DockerTrustSigner bypass DI — PARTIALLY ADDRESSED

DockerTrust itself is now registered in DockerExtensions.Generated.cs:

services.TryAddScoped<DockerTrust>();

This is progress. However, DockerTrust.Generated.cs still instantiates its sub-services with new:

public DockerTrustKey Key => _key ??= new DockerTrustKey(_command);
public DockerTrustSigner Signer => _signer ??= new DockerTrustSigner(_command);

DockerTrustKey and DockerTrustSigner are not registered with DI, which means they cannot be resolved independently, cannot be substituted in tests, and cannot receive their own scoped dependencies if the generator ever adds any. By contrast, DockerPlugin, DockerSwarm, DockerSystem, and DockerVolume are all DI-registered and constructor-injected into Docker. The fix is to also register DockerTrustKey and DockerTrustSigner via TryAddScoped, then inject them into DockerTrust's constructor rather than creating them lazily with new. This would make the pattern fully consistent.

Issue 3: Timeout typed as string? — PERSISTS (new this cycle)

Raised in the 2026-03-22 review and still present across all builder commands:

[CliOption("--timeout", Format = OptionFormat.EqualsSeparated)]
public string? Timeout { get; set; }

Using string? for a duration option forfeits type safety. A caller has no guidance on the expected format from the property type alone. Consider TimeSpan? with a formatter, or at minimum ensure the XML doc comment includes the expected format string (e.g., "20s", "1m30s"). The current comment only says "default 20s" which does not show the caller what formats are accepted.

Issue 4: docker bake removal — STILL PRESENT

DockerBakeOptions, Bake() in Docker.Generated.cs, and the Bake() method in IDocker have all been removed. docker bake is an active BuildKit command. If this removal is due to the scraping environment not having BuildKit context available, it represents a tooling version gap rather than a genuine API removal, and it silently breaks any existing user code calling context.Docker().Bake(...). This warrants a changelog entry at minimum.

---

New Observation This Cycle

DisableContentTrust added broadly — worth a note

--disable-content-trust has been added to a large number of commands (pull, push, create, run, plugin install/upgrade, and others). This is consistent with Docker's flag and is correctly typed as bool?. No issues with the implementation, but it is worth noting in release notes since it expands the API surface noticeably.

---

Summary

Issue	Status
Truncated XML doc (DockerTrustSignerRemoveOptions)	Still present — needs generator fix
DockerTrustKey/DockerTrustSigner not DI-registered	Partially fixed (DockerTrust now registered, sub-services still use new)
Timeout as string? instead of TimeSpan?	Still present
docker bake removed silently	Still present — needs changelog entry

The most impactful remaining action is completing the DI registration for DockerTrustKey and DockerTrustSigner in the generator, so the DockerTrust sub-group follows the same pattern as all other service groups in this library.

[claude]

Code Review: [Automated] Update docker CLI Options (2026-04-05)

This review checks the current re-generation against all issues raised in every prior review (2026-03-01 through 2026-03-29).

---

Status of Previously Raised Issues

Issue 1: Truncated XML doc comment in DockerTrustSignerRemoveOptions — STILL UNRESOLVED (6th review)

/// <summary>
/// Do not prompt for confirmation before removing the most
/// </summary>

This has appeared in every single automated generation since DockerTrust was first introduced. The Docker CLI help text reads: "Do not prompt for confirmation before removing the most recently added signer". The generator is truncating at a line-length boundary mid-sentence. This is a straightforward bug in the generator's CLI help text parsing: it reads only the first line of a wrapped help string instead of joining continuation lines. The fix belongs in tools/ModularPipelines.OptionsGenerator/ — without it, this broken doc comment will appear in every future automated PR indefinitely.

Issue 2: DockerTrustKey and DockerTrustSigner bypass DI — STILL UNRESOLVED (6th review)

DockerTrust itself is now correctly DI-registered (services.TryAddScoped<DockerTrust>()), but its sub-services are still instantiated with new:

public DockerTrustKey Key => _key ??= new DockerTrustKey(_command);
public DockerTrustSigner Signer => _signer ??= new DockerTrustSigner(_command);

Every other service group at this depth (DockerPlugin, DockerSwarm, DockerSystem, DockerVolume) is registered in DI and constructor-injected into Docker. The sub-services under DockerTrust are the only exception. The fix is: register DockerTrustKey and DockerTrustSigner with services.TryAddScoped<T>() in the generator's DI registration template, then inject them into DockerTrust's constructor. Until this is done, they cannot be independently mocked in tests and cannot receive their own scoped dependencies.

Issue 3: Timeout as string? instead of a typed duration — STILL PRESENT (3rd review)

[CliOption("--timeout", Format = OptionFormat.EqualsSeparated)]
public string? Timeout { get; set; }

This appears across all seven builder subcommands (Create, Du, Inspect, Ls, Prune, Rm for both builder and buildx). Using string? for a duration option forfeits type safety — callers have no guidance from the type system on what format is expected. The doc comment says only "default 20s" but does not show the accepted format string (e.g., "1m30s", "2h"). At minimum, the doc comment should show accepted format examples. The longer-term fix is a duration type or at least a note in the XML doc summary.

Issue 4: docker bake removed — STILL PRESENT (6th review)

DockerBakeOptions, IDocker.Bake(), and Docker.Bake() are all removed. docker bake is an active BuildKit command. This is likely a scraping environment issue (the build agent's Docker CLI is missing BuildKit context), not a genuine API removal. This is a silent breaking change for any user calling context.Docker().Bake(...). Worth a changelog entry at minimum; worth investigating whether the CI agent used for generation has BuildKit available.

---

What's New in This Generation (2026-04-05)

No new issues introduced. The diff relative to the prior generation (2026-03-29) is minor:

• Timestamp bump in AssemblyInfo.Generated.cs
• Whitespace normalization in DockerBuilder/DockerBuildx XML doc comments ("--builder string Override" → "--builder string Override") — cosmetic only

---

Summary

Issue	Status	Reviews Outstanding
Truncated XML doc (DockerTrustSignerRemoveOptions)	Unresolved	6
DockerTrustKey/DockerTrustSigner not DI-registered	Unresolved	6
Timeout typed as string?	Unresolved	3
docker bake silently removed	Unresolved	6

The generated output itself is structurally correct and consistent. However, the same four generator-level issues have persisted through every automated PR since the DockerTrust group was introduced. Since this PR is auto-merged, the issues will continue to accumulate with each re-generation until the generator is fixed. The truncated XML doc comment and the DI inconsistency are the highest priority — the former ships broken IDE tooltips to every user of the package, and the latter creates a subtle testability gap that will only grow if the nested sub-services ever need injected dependencies.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 19 complexity

Metric	Results
Complexity	✅ 19 (≤ 20 complexity)

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}