This was a bad configuration (my fault) that meant each span was
exported synchronously, as it ended. That can cause weird behavior
such as stuttering/blocking.
There's really no reason to NOT use the batch processor, it's the
recommended way to configure it. In the future, it might make sense
to tune the intervals based on the fact that Compose is a CLI vs
a long-running server app, but we handle flushing out on exit
already, so it's not a huge deal.
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>
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>
I noticed that the CLI was still on 20.10, but the daemon on 24.0.7;
Docker info
/usr/bin/docker version
Client:
Version: 20.10.17
API version: 1.41
Go version: go1.17.11
Git commit: 100c701
Built: Mon Jun 6 22:56:42 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 24.0.7
API version: 1.43 (minimum version 1.12)
Go version: go1.20.10
Git commit: 311b9ff
Built: Thu Oct 26 09:07:41 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.26
GitCommit: 3dd1e886e55dd695541fdcd67420c2888645a495
runc:
Version: 1.1.10
GitCommit: v1.1.10-0-g18a0cb0
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Guillaume Lours
Nicolas De Loof
Milas Bowman
Sebastiaan van Stijn
David Karlsson
Laura Brehm
Sebastiaan van Stijn
dependabot[bot]
Brian Goff
Wes Higbee