This has not been the default for quite a while and required
setting an environment variable to revert back.
The tar implementation is more performant and addresses several
edge cases with the original `docker cp` version, so it's time
to fully retire it.
The scaffolding for multiple sync implementations remains to
support future experimentation here.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Previously, we included the container's primary network in the
ContainerCreate API call, and then connected the created container
to each extra network one-by-one, by calling NetworkConnect.
However, starting API version 1.44, the ContainerCreate endpoint now
takes multiple EndpointsConfigs, allowing us to just include all the
network configurations there and skip connecting the container to each
extra network separately.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Build{x,kit} support passing in source policies via an (expirimental)
env var.
This change adds those policies to the build request.
Signed-off-by: Brian Goff <cpuguy83@gmail.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>
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>
