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>
Print more understandable messages on error:
- When ps fails because the monitor doesn't attach to any session, print "no
attaching session" instead of "unknown ref".
- Avoid disconnect silently fails when the monitor doesn't attach to any
session. Print "no attaching session" error instead.
- Fix error message of "attach"'s arguments. ("server name must be passed" ->
"ID of session or process must be passed")
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
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>
This commit moves monitor commands to `monior/commands` package.
Commands still need access to the `monitor` object and buildx controller so this
commit enables this via `Monitor` interface stored in `monitor/types`.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.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>
* Return errors from creating the `NodeGroup`
* Ensure that `b.NodeGroup != nil` before reading from
it during validation
Signed-off-by: Milas Bowman <milas.bowman@docker.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>
