Add builder.output_options configuration for buildx output parameters#1843
Add builder.output_options configuration for buildx output parameters#1843sjparkinson wants to merge 4 commits into
builder.output_options configuration for buildx output parameters#1843Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a new builder.output configuration option to let users append Docker buildx output type parameters (e.g., compression settings) to the docker buildx build --output=... invocation used during image pushes.
Changes:
- Add
builder.outputto configuration and expose it viaKamal::Configuration::Builder. - Append configured output parameters to the buildx
--outputflag duringbuilder.push. - Document the new setting and add configuration/command coverage in tests.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| test/configuration/builder_test.rb | Adds tests for default and configured builder.output. |
| test/commands/builder_test.rb | Ensures buildx push command includes appended output parameters. |
| lib/kamal/configuration/docs/builder.yml | Documents the new builder.output config option (and drives config validation). |
| lib/kamal/configuration/builder.rb | Adds output accessor to the builder configuration object. |
| lib/kamal/commands/builder/base.rb | Extends buildx push command to include the configured output parameters. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Output | ||
| # | ||
| # Docker output type parameters appended to the buildx `--output=type=...` flag. | ||
| # Useful for configuring the compression type: | ||
| output: compression=zstd,compression-level=3,force-compression=true |
There was a problem hiding this comment.
The PR title mentions builder.outputs, but the actual config key documented/implemented here is builder.output (singular). To avoid confusing users, align the naming across the PR title/docs/implementation (either rename the key or update the title/wording to singular).
There was a problem hiding this comment.
I think we should go with something like:
output_options:
compression: zstd
compression-level: 3
force-compression: trueAnd raise a configuration error if type is set as Kamal controls that itself.
builder.outputs configuration for buildx output parametersbuilder.output configuration for buildx output parameters
| # Output | ||
| # | ||
| # Docker output type parameters appended to the buildx `--output=type=...` flag. | ||
| # Useful for configuring the compression type: | ||
| output: compression=zstd,compression-level=3,force-compression=true |
There was a problem hiding this comment.
I think we should go with something like:
output_options:
compression: zstd
compression-level: 3
force-compression: trueAnd raise a configuration error if type is set as Kamal controls that itself.
builder.output configuration for buildx output parametersbuilder.output_options configuration for buildx output parameters
A `builder.output: ""` config produced `--output=type=registry,`, which buildx rejects.
b4330e9 to
86bd591
Compare
| case key.to_s | ||
| when "options", "args" | ||
| validate_type! value, Hash | ||
| when "labels" | ||
| when "labels", "output_options" | ||
| validate_hash_of! value, example_value.first[1].class |
There was a problem hiding this comment.
Shout if this is a concern to address. Because a string value comes first in the example this works fine right now.
This change adds a new configration option, that allows you to pass buildx build output parameters1.
I can see this mainly being used to configure compression.
For a bit of context, I found #1549 when trying to sort this out myself today.
Using zstd should(?) be a bit faster to deploy that the default gzip, compression level 3 is the default level. I'm using the patch from the discussion on a Ubuntu Hetzner VM with no issues. Useful when deploying locally on a slow upstream connection with a local registry.
Configuration would look like:
Worth noting,
kamal build pushalready supports an--outputoption, so you could achieve this today as a two command deploy:Footnotes
https://docs.docker.com/build/exporters/image-registry/#synopsis ↩