This adds an env var which can be used to pass in a path to a file to
read a buildkit source poliy from.
This is applied to any build is executed with the env set.
It is also applied to bakes (which are calling build behind the scenes).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
BuildKit's gitutil package behaves slightly differently than moby's
urlutil, so we should rely on BuildKit's gitutil when detecting URLs to
avoid cases of accidentally producing invalid build requests that can
confuse users.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This allows the build package code to become more generic, and also
ensures that when the environment variables are not propogated (in the
case of the remote controller), that we can still correctly set
SOURCE_DATE_EPOCH.
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>
Now clients can access the result of the solve, specifically the image
id output. This is a useful refactor, as well as being required if we
want to allow bake to invoke through the controller api.
This also allows us to remove the quiet option from the API, since we
can compute the required progress type outside of the controller, and
can print the image id from the result of the solve.
As a follow-up, we should also be able to remove the image id file
output from the controller api, now that the client has access to it.
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>
For certain cases we need to build with `--provenance=false`.
However not all build envs (especially in the OSS ethos) have the latest
buildx so just blanket setting `--provenance=false` will fail in these
cases.
Having an env var allows people to set the value without having to worry
about if the buildx version has the `--provenance` flag.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
We should avoid erroring with attestations support compatability errors
when a user has specified --provenance=false.
A user may wish to enable --provenance=false that works across buildkit
versions, but currently it will fail on old versions - this patch fixes
this, to silently ignore the provenance flag for this check if it's set
to disabled.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Using the syncronization primitive, we can avoid needing to create a
separate wait group.
This allows us to sidestep the issue where the wait group could be
completed, but the build invocation functions had not terminated - if
one of the functions was to terminate with an error, then it was
possible to encounter a race condition, where the result handling code
would begin executing, despite an error.
The refactor to use a separate error group which more elegantly handles
the concept of function returns and errors, ensures that we can't
encounter this issue.
Signed-off-by: Justin Chadwell <me@jedevc.com>
All build options should be passed everywhere - the frontend and the
backend of buildkit should both be able to see all attestations, as well
as all other opts: e.g. epoch settings, and no-cache.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We allow any valid image reference format for the oci-layout, not just
limiting to name@digest, we additionally allow images of the form
name:tag@digest now.
The name of the reference is used to find the local directory to lookup
the store in, while the tag and digest are attached to a random identity
to generate the dummy reference sent to the oci-layout context.
This separation of the target to replace and the value to replace it
with ensures that any tag or digest set in the client is properly sent
across to the server. The tag is used when a digest was not specified,
and it is resolved in the context of the local directory before being
sent, using the same helpers as we use for the local cache expoter.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Justin Chadwell