This wasn't always getting passed, so adding it to the wrapper
function where it'll pass the `WithContext()` loader method at
the last moment.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
The changes in
dcbf005fe4
fixed the "cancellable context" detection, and made it so that Compose
would conditionally set up signal handling when the context was already
not cancellable/when the plugin was running through the CLI, as we'd
introduced a mechanism into the CLI to signal plugins to exit through a
socket instead of handling signals themselves.
This had some (not noticed at the time) issues when running through the
CLI as, due to sharing a process group id with the parent CLI process,
when a user CTRL-Cs the CLI will notify the plugin via the socket but
the plugin process itself will also be signalled if attached to the TTY.
This impacted some Compose commands that don't set up signal handling -
so not `compose up`, but other commands would immediately quit instead
of getting some "graceful" cancelled output.
We initially attempted to address this "double notification" issue in
the CLI by executing plugins under a new pgid so that they wouldn't be
signalled, but that posed an issue with Buildx reading from the TTY,
(see: https://github.com/moby/moby/issues/47073) so we reverted the
process group id changes and ended at a temporary solution in
https://github.com/docker/cli/pull/4792 where the CLI will only notify
plugins via the socket when they are not already going to be signalled
(when attached to a TTY).
Due to this, plugins should always set up some signal handling, which
this commit implements.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
When using the Moby/Docker Engine API client, we do not have a
useful user agent value being reported. Ideally, in the future,
the Docker CLI will set this appropriately for plugins when it
initializes the client.
For now, manually set it, which is a bit hacky because it
requires some casting & manually invoking an option function
that's technically meant for initialization. In practice, this
is pretty safe - the cast is checked defensively and we ignore
any errors (which shouldn't be possible anyway).
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Previously, if a long-lived plugin process (such as
an execution of `compose up`) was running and then
detached from a terminal, signalling the parent CLI
process to exit would leave the plugin process behind.
To address this, changes were introduced on the CLI side
(see: https://github.com/docker/cli/pull/4599) to enable
the CLI to notify a running plugin process that it should
exit. This makes it so that, when the parent CLI process
is going to exit, the command context of the plugin
command being executed is cancelled.
This commit takes advantage of these changes by tapping into
the command context's done channel and using it to teardown
on an up.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
`AdaptCmd` was previously checking for a `.WithCancel` suffix
on context strings, however it's possible for a context to be
cancellable without ending in that suffix, such as when
`context.WithValue` was called after `WithContext`, e.g.:
```go
context.Background.WithCancel.WithValue(type trace.traceContextKeyType,
val <not Stringer>).WithValue(type api.DryRunKey, val <not Stringer>)
```
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This default behaviour will force a rebuild of the service images at watch process startup and be sure containers will be in sync with the local source code
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
From the Go specification [1]:
"1. For a nil slice, the number of iterations is 0."
`len` returns 0 if the slice is nil [2]. Therefore, checking
`len(v) > 0` before a loop is unnecessary.
[1]: https://go.dev/ref/spec#For_range
[2]: https://pkg.go.dev/builtin#len
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Nicolas De Loof
Piotr Dąbrowski
jhrotko
1arp
Milas Bowman
Guillaume Lours
Laura Brehm
Wes Higbee
Amit Saha
szampardi
Matthew Walowski
Eng Zer Jun