Skip to content

[Automated] Update docker CLI Options#2408

Open
thomhurst wants to merge 1 commit intomainfrom
automated/update-cli-options-docker
Open

[Automated] Update docker CLI Options#2408
thomhurst wants to merge 1 commit intomainfrom
automated/update-cli-options-docker

Conversation

@thomhurst
Copy link
Owner

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

@thomhurst thomhurst added automated dependencies Pull requests that update a dependency file labels Feb 22, 2026
@thomhurst thomhurst enabled auto-merge (squash) February 22, 2026 03:11
@thomhurst thomhurst force-pushed the automated/update-cli-options-docker branch from 5778a22 to a8e9d02 Compare March 1, 2026 03:13
Copy link

@claude claude bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant