Proposal: Add build `--compression` flag

[vvoland]

Description

Add --compression flag as a shorthand for: -o type=image,compression=<X>

Examples

-docker build -t asdf -o type=image,compression=zstd
+docker build -t asdf --compression zstd

-docker build -t asdf -o type=image,compression=uncompressed
+docker build -t asdf --compression uncompressed

Further enhancements

Also supportcompression-level

-docker build -t asdf -o type=image,compression=zstd,compression-level=1
+docker build -t asdf --compression zstd:1

Shorthand for uncompressed value

Optionally, provide none/false value as a shorthand for uncompressed:

-docker build -t asdf -o type=image,compression=uncompressed
+docker build -t asdf --compression none

Short flag

-c/--compressed

-docker build -t asdf -o type=image,compression=uncompressed
+docker build -t asdf -c none

[tonistiigi]

Note that -o is an array of outputs

Edit: Reading again it looks like you are suggesting not modifying -o but inserting. In that case, outputs like oci, docker also create images.

[vvoland]

Yep, would be good if this would also work for oci (although it seems like it isn't configurable yet: https://github.com/moby/buildkit/blob/d42d8a3421b62a4ba6d71141b32a945520182537/exporter/oci/export.go#L71)

For docker - I think it's less important because the legacy graphdrivers unpack the image anyway and don't store the compressed form.

[tonistiigi]

(although it seems like it isn't configurable yet:

It works through https://github.com/moby/buildkit/blob/d42d8a3421b62a4ba6d71141b32a945520182537/exporter/oci/export.go#L77 https://github.com/moby/buildkit/blob/d42d8a3421b62a4ba6d71141b32a945520182537/exporter/containerimage/opts.go#L42-L64

[vvoland]

Hmm right. So ultimately what I'm suggesting here is a --compression flag that would configure all output exporters with the specified compression.

[polarathene]

--compression zstd:1

What would this look like for zstd:chunked? (if supported in future) zstd-chunked:1?

For reference Podman has:

• --compression-format=zstd:chunked + --compression-level (no convenience shorthand to specify level with format).
• podman build doesn't have that option explicitly documented, but they do have --disable-compression (enabled by default), on the basis that built image is stored uncompressed locally and only compressed when pushed to a registry. With buildx that depends on the build driver or image store AFAIK.
• Podman also supports an --add-compression option but is for podman manifest push
  • Which is convenient for pushing images with gzip + zstd, with the correct order (gzip first IIRC) for older clients to select the first image to pull whilst more modern clients would prefer zstd by default when available.
  • --compression-level becomes ambiguous in this scenario? Pragmatically adjusting the level should be rare and one may prefer a global config tunable instead?
  • Seems to be a known issue to support multiple exporters in buildkit presently.

nerdctl:

• Has specific options for estargz gzip and zstd:chunked variants for it's commit and image convert subcommands, which is a little confusing/messy, given they're both delegated to the same eStargz snapshotter project 😓
• Equivalent in nerdctl build command support is missing as it delegates to buildkit.

Just thought I'd bring that up if there's any interest in consistency with existing tooling.

---

--force-recompression may also be relevant to support? I'm not sure how advisable it is to push images with a mix of different compressed layers? While I'm familiar with the setting the docs don't convey the impact of this feature, would subsequent builds need to recompress or would the layer built/pushed previously to local/registry be reused?

Might be worth considering how likely such options would be adopted. If it's mostly for convenience and would otherwise be static preference onwards, then config / ENV to make these defaults might be just as valid? Experimentation can otherwise be done manually via --output or with Bake's HCL to set variables via CLI without needing dedicated CLI options.