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>
The code used an atomic bool to guard channel writes. However, this
failed to synchronize with the call to close(), causing a panic.
Fix the race condition by using a mutex to guard the update to the
bool `stopped` and subsequent channel writes. This ensures atomic
execution of both updates to `stopped` and channel writes, preventing
races between writes and close().
Signed-off-by: horus <horus.li@gmail.com>
Related to:
- https://github.com/compose-spec/compose-spec/pull/435
- https://github.com/moby/moby/pull/45905
Since API v1.44, Moby supports a per-endpoint MAC address and returns a
warning when the container-wide mac_address field is set.
A corresponding field has been added to compose-spec and compose-go, so
we need to leverage it to set the right API field.
This commit is backward-compatible with compose files that still set the
container-wide mac_address field, and older API versions that don't know
about the endpoint-specific MAC address field.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Currently, we publish Compose artifacts following the OCI 1.1
specification, which is still in the RC state.
As a result, not all registries support it yet. Most notably,
AWS ECR will reject certain OCI 1.1-compliant requests with
`405 Method Not Supported` with cryptic `Invalid JSON` errors.
This adds initial support for Compose to generate either an
OCI 1.0 or OCI 1.1 compatible manifest. Notably, the OCI 1.0
manifest will be missing the `application/vnd.docker.compose.project`
artifact type, as that does not exist in that version of the
spec. (Less importantly, it uses an empty `ImageConfig`
instead of the newer `application/vnd.oci.empty.v1+json` media
type for the config.)
Currently, this is not exposed as an option (via CLI flags or
env vars). By default, OCI 1.1 is used unless the registry
domain is `amazonaws.com`, which indicates an ECR registry, so
Compose will instead use OCI 1.0.
Moving forward, we should decide how much we want to expose/
support different OCI versions and investigate if there's a
more generic way to feature probe the registry to avoid
maintaining a hardcoded list of domains, which is both tedious
and insufficient.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
