Port of moby/buildkit#6569 to buildx. Adds --memory, --memory-swap,
--cpu-shares, --cpu-period, --cpu-quota, --cpuset-cpus, and --cpuset-mems
flags to build, plus the equivalent bake target attributes and compose
x-bake fields.
Signed-off-by: Jiří Moravčík <jiri.moravcik@gmail.com>
Removes all references to the controller and moves the remaining
sections of code to other packages.
Processes has been moved to monitor where it is used and the data
structs have been removed so buildflags is used directly. The controller
build function has been moved to the commands package.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Broken in 11c84973ef. The section to skip
an empty input was accidentally removed when some code was refactored to
fix a separate issue.
This skips empty cache entries which allows disabling the `cache-from` and
`cache-to` entries from the command line overrides.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Allow access to CDI Devices in Buildkit v0.20.0+ for
devices that are not automatically allowed to be used by
everyone in BuildKit configuration.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
Some repositories already have v2 enabled and that
causes errors avainst older BuildKit. To avoid that we
need to send both URLs as separate keys.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Reverts the usage of rangefunc and attempts to keep the foundation of it
in for when we move to go 1.23. We have downstream dependencies that
aren't ready to move to go 1.23. We can likely move after go 1.24 is
released.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Update the buildflags cty code to handle unknown values. When hcl
decodes a value with an invalid variable name, it appends a diagnostic
for the error and then returns an unknown value so it can continue
processing the file and finding more errors.
The iteration code has now been changed to use a rangefunc from go 1.23
and it skips empty or unknown values. Empty values are valid when they
are skipped and unknown values will have a diagnostic for itself.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
`MarshalJSON` would not include the extra attributes because it iterated
over the target map rather than the source map.
Also fixes JSON unmarshaling for SSH and secrets. The intention was to
unmarshal into the struct, but `UnmarshalText` takes priority over the
default struct unmarshaling so it didn't work as intended.
Tests have been added for all marshaling and unmarshaling methods.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This changes how the composable attributes are implemented and provides
various fixes to the first iteration.
Cache-from and cache-to now no longer print sensitive values that are
automatically added. These automatically added attributes are added when
the protobuf is created rather than at the time of parsing so they will
no longer be printed. If they are part of the original configuration
file, they will still be printed.
Empty strings will now be skipped. This was the original behavior and
composable attributes removed this functionality accidentally. This
functionality is now restored.
This also expands the available syntax that works with each of the
composable attributes. It is now possible to interleave the csv syntax
with the object syntax without any problems. The canonical form is still
the object syntax and variables are resolved according to that syntax.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This allows using either the csv syntax or object syntax to specify
certain attributes.
This applies to the following fields:
- output
- cache-from
- cache-to
- secret
- ssh
There are still some remaining fields to translate. Specifically
ulimits, annotations, and attest.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The Docker docs in multiple places describe passing an annotation at the
command line like "index,manifest:com.example.name=my-cool-image", and
say that this will result in the annotation being applied to both the
index and the manifest. It doesn't seem like this was actually
implemented, and instead it just results in an annotation key with
"index,manifest:" at the beginning being applied to the manifest.
This change splits the part of the key before the colon by comma, and
creates an annotation for each type/platform given, so the
implementation should now match the docs.
Signed-off-by: Eli Treuherz <et@arenko.group>
This extracts the same logic for parsing annotations from the imagetools
create command, and allows the same flags to be attached to the build
command.
These annotations are then merged into all provided exporters.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Use buildkit's parsing of entitlements to make sure that accepted
values match what's accepted by BuildKit.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When the user supply static creds, we must not enrich them with a
session token which is unrelated.
Signed-off-by: Bertrand Paquet <bertrand.paquet@gmail.com>
This ensures that `target.attest=["type=sbom,<value>"]` can be
appropriately merged when `--sbom=true` or `--set
target.attest=type=sbom`.
To merge, we simply naively take the last valid value.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This will allow result printing to work with the remote controller
(though this currently causes a panic, to be fixed in a follow-up).
Signed-off-by: Justin Chadwell <me@jedevc.com>
We can perform all attestation processing, handling how the sbom and
provenance arguments interact on the client, while applying defaults on
the server.
Additionally, this allows us to start pulling fields out of CommonOpts.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Strongly typing the API allows us to perform all command line parsing
fully on the client-side, where we have access to the client local
directory and all the client environment variables, which may not be
available on the remote server.
Additionally, the controller api starts to look a lot like
build.Options, so at some point in the future there may be an
oppportunity to merge the two, which would allow both build and bake to
execute through the controller, instead of needing to maintain multiple
code paths.
Signed-off-by: Justin Chadwell <me@jedevc.com>
CrazyMax