feat: add docker build custom options
This PR allows providing any command line options to docker build by accepting them from an array of string instead of trying to define them all one by one.
For now, only --target & --cache-from are supported since https://github.com/aws/copilot-cli/pull/1555, but we cannot anticipate every single new options (as those used by buildx, or secret files, for instance).
Example:
image:
dockerfile: path/to/dockerfile
options: [ --target, my-target ]
image:
build:
dockerfile: path/to/dockerfile
options:
- --pull
- --builder
- my-buildx-builder
- --cache-from
- type=registry,mode=max,compression-level=1,ref=${CI_REGISTRY_IMAGE}/web:latest-cache
- --cache-to
- type=registry,mode=max,compression-level=1,ref=${CI_REGISTRY_IMAGE}/web:latest-cache
- --secret
- id=npmrc,src=.npmrc
Using an array of strings is not really readable when declaring options prefixed with a --. The alternative would be passing the options as a single or multilines string, but this would be a lot less flexible. What do you think about it ?
Fixes https://github.com/aws/copilot-cli/issues/2090, fixes https://github.com/aws/copilot-cli/issues/3466
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.
🍕 Here are the new binary sizes!
| Name | New size (kiB) | size (kiB) | Delta (%) |
|---|---|---|---|
| macOS (amd) | 58088 | 58072 | +0.03 |
| macOS (arm) | 59136 | 59136 | ❤️ 0.00 |
| linux (amd) | 50936 | 50924 | +0.02 |
| linux (arm) | 50176 | 50180 | ❤️ -0.01 |
| windows (amd) | 47972 | 47968 | +0.01 |
Hello, @mRoca!
Thanks so much for your contribution! You're absolutely right that your proposed changes would make our manifests more nimble for Docker options; unfortunately, any manifest changes need to be backwards-compatible so existing workloads don't break. We can't consolidate our existing build options into a more general options field at this point.
We could theoretically add the options field and hide the existing --target and --cache-from fields but still handle them exactly as we have, combining them with any options in the options field. But your questions correctly suggest that the input and parsing of the list of options would require some amount of thought, guidance, and tons of validation.
Thanks again!
Hi @huanjani , I don't get your point :-/ I've indeed added the options yaml field, while still handling old --target and --cache-from fields (even if they are not documented anymore), in order to avoid any bc break. What do you suggest I should add to the PR ?
What changes would be needed to this PR to get it merged?