This was missing, since the driver property can only be fully populated
after loading nodes from disk. So we add logic to load the nodes, and
check for an error, which ensures that the "docker" driver is always
correctly present in the progress description.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This doesn't require pulling in a new direct dependency, we already use
docker/distribution throughout imagetools and build.
Signed-off-by: Justin Chadwell <me@jedevc.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 fixes a possible race where messages printed directly after calls
to NewPrinter may appear before the printer starts. With this change, we
delay all of the logs until after.
Signed-off-by: Justin Chadwell <me@jedevc.com>
kind labels should only be manually added by maintainers after
confirming the issue. Otherwise, it can be tricky to sort through all
the issues when filtering for legitimate bugs.
Signed-off-by: Justin Chadwell <me@jedevc.com>
--detach shouldn't be the default yet, since it still has the potential
to leak some sessions in odd edge cases, and is slightly more painful to
debug.
For now, we should set the local controller as the default, with the
idea that we can change it back in the future.
Signed-off-by: Justin Chadwell <me@jedevc.com>
compose-go v1.13.0 supports the new additional_contexts to allow passing
additional build context during build, so we should map this to bake's
contexts property.
Signed-off-by: Justin Chadwell <me@jedevc.com>
compose-go v1.13.0 supports the new dockerfile_inline to allow including
a dockerfile inline in the compose definition, so we should map this to
bake's dockerfile-inline property.
Signed-off-by: Justin Chadwell <me@jedevc.com>
When resolving remote contexts locally in bake, then we need to ensure
that we properly unpack the contents of that context to the root
directory, instead of leaving it in the subdirectory.
Otherwise, any files will be found in the wrong location. Along with
this change, we also need a change to the dockerfile location lookup to
ensure that it is found at the root instead of in the subdirectory.
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>
logrus info messages aren't particularly in-theme with the rest of the
progress output (and are also frustratingly racy). The progress output
is a lot neater, so we refactor it into that.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Refactor the progress printer creation to the caller-side of the
controller api. Then, instead of passing around status channels (and
progressMode strings), we can simply pass around the higher level
interface progress.Writer.
This has a couple of benefits:
- A simplified interface to the controller
- Allows us to correctly extract warnings out of the controller, so that
they can be displayed correctly from the client side.
Some extra work is required to make sure that we can pass a
progress.Printer into the debug monitor. If we want to keep it
persistent, then we need a way to temporarily suspend output from it,
otherwise it will continue printing as the monitor is prompting for
input from the user, and forwarding output from debug containers.
To handle this, we add two methods to the printer, `Pause` and
`Unpause`. `Pause` acts similarly to `Wait`, closing the printer, and
cleanly shutting down the display - however, the printer does not
terminate, and can later be resumed by a call to `Unpause`. This
provides a neater interface to the caller, instead of needing to
continually reconstruct printers for every single time we want to
produce progress output.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We had some duplicated code between the basic runBuild and
launchControllerAndRunBuild.
This patch refactors out the common logic (since it's only really like
to keep growing), and has runBuild call into either the controller or
directly start the build depending on whether BUILDX_EXPERIMENTAL is
set.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This ensures that the code used to capture and evaluated a result is
only executed when built through the controller. Otherwise, no build
result should be recorded.
This ensures that new code added to capture and store the build result
for debugging isn't used when BUILDX_EXPERIMENTAL is not set.
Signed-off-by: Justin Chadwell <me@jedevc.com>
In 566f41b598, we added a check to ensure
that we avoid resolving http URLs for Dockerfile. However, we have
another circumstance we should not resolve the path in - if the context
is a remote context, the dockerfile is resolved in that context (see
build.go#LoadInputs for more information).
Therefore, we should only resolve the dockerfile to a local directory if
the context is also resolved to a local directory.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Dockerfiles can be HTTP URLs as well as local paths 🤦
We just copy the same logic we use for resolving context paths, and
apply it here as well.
Signed-off-by: Justin Chadwell <me@jedevc.com>
The updateContext function may make modifications to the build inputs,
creating either an SSH URL, or an SSH llb.State. In these cases, we need
to ensure that we appropriately expose the client's default agent.
Previously, we would only expose it if the remote context was a git URL,
however, we need to also ensure that if the input was used to override
the context (in the case of ReadRemoteFiles), that we expose the agent
here as well.
Signed-off-by: Justin Chadwell <me@jedevc.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 adds the following constraints to the new features:
- Explicit renaming with the `name` property is *only* permitted when
used with the `matrix` property.
- Group does not support either `name` or `matrix` (we may choose to
relax this constraint over time).
- All generated names must be unique.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Previously, we would explicitly error if all TLS parameters were not
available. However, it is a perfectly valid use case to connect to a
buildkit server that only provides TLS in one direction to verify the
server (which is possible today with buildctl).
To support this use case, we only need to error if only one of key or
cert is set, and the other is not - if both are unspecified, the client
will not present a certificate to the server.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Previously, the name property could not be set in the body of a bake
target and could only be set for a label. This patch allows the body to
override the values of label fields, though the default is still the
label.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This patch allows high level clients to define an EvalContext method
which can derive a new context given a block and the base parent
context.
This allows users of the package to intercept evaluation before it
begins, and define additional variables and functions that are bound to
a single block.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Previously, when directly modifying the args map when reading targets,
we could end up in a scenario where bake tests that compare arg maps
would fail if SOURCE_DATE_EPOCH was set in the environment.
This patch prevents this failure by setting the SOURCE_DATE_EPOCH at the
command level (which isn't injected into tests as well), ensuring that
we test correctly even when SOURCE_DATE_EPOCH is set in the environment.
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>