In order to solve the "double notification" issue (see:
ef5e5fa03f)
without running the plugin process under a new pgid (see:
https://github.com/moby/moby/issues/47073) we instead check if we're
attached to a TTY, and if so skip signalling the plugin process since it
will already be signalled.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This reverts commit ef5e5fa03f.
Running new plugins under a new pgid isn't a viable solution due to
it causing issues with plugin processes attempting to read from the
TTY (see: https://github.com/moby/moby/issues/47073).
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Looks like this change caused docker-ce-packaging to fail;
dest=$PWD/build/mac; cd /home/ubuntu/workspace/release-packaging_ce-nightly/packaging/src/github.com/docker/cli/build && for platform in *; do \
arch=$(echo $platform | cut -d_ -f2); \
mkdir -p $dest/$arch/docker; \
cp $platform/docker-darwin-* $dest/$arch/docker/docker && \
tar -C $dest/$arch -c -z -f $dest/$arch/docker-25.0.0-rc.2.tgz docker; \
done
cp: cannot stat 'darwin_amd64/docker-darwin-*': No such file or directory
cp: cannot stat 'darwin_arm64/docker-darwin-*': No such file or directory
This reverts commit 6ad07f2a4b.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Changes were made in 1554ac3b5f to provide
a mechanism for the CLI to notify running plugin processes that they
should exit, in order to improve the general CLI/plugin UX. The current
implementation boils down to:
1. The CLI creates a socket
2. The CLI executes the plugin
3. The plugin connects to the socket
4. (When) the CLI receives a termination signal, it uses the socket to
notify the plugin that it should exit
5. The plugin's gets notified via the socket, and cancels it's `cmd.Context`,
which then gets handled appropriately
This change works in most cases and fixes the issue it sets out to solve
(see: https://github.com/docker/compose/pull/11292) however, in the case
where the user has a TTY attached and the plugin is not already handling
received signals, steps 4+ changes:
4. (When) the CLI receives a termination signal, before it can use the
socket to notify the plugin that it should exit, the plugin process
also receives a signal due to sharing the pgid with the CLI
Since we now have a proper "job control" mechanism, we can simplify the
scenarios by executing the plugins with their own process group id,
thereby removing the "double notification" issue and making it so that
plugins can handle the same whether attached to a TTY or not.
In order to make this change "plugin-binary" backwards-compatible, in
the case that a plugin does not connect to the socket, the CLI passes
the signal to the plugin process.
Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
As macOS does not support the abstract socket namespace, use a temporary
socket in $TMPDIR to connect with the plugin. Ensure this socket is
cleaned up even in the case of crash/ungraceful termination by removing
it after the first connection is accepted.
Co-authored-by: Laura Brehm <laurabrehm@hey.com>
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Build and push an image containing a static CLI binary for master branch
and every release branch and tag.
This is a slightly adjusted copy of the bin-image workflow from
docker/buildx (by @crazy-max).
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Transform `VERSION` variable if it contains a git ref.
This is the same as moby does (with "<<<" bashism removed).
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
`scripts/make/binary` produces `docker` file that is a symlink to a
`docker-<platform>` file.
Make the `binary` Dockerfile target produce an image that only contains
the `docker` binary and not the symlink.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Update this function to accept a smaller interface, as it doesn't need
all of "CLI". Also return errors encountered during its operation (although
the caller currently has no error return on its own).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Slightly rephrase the intro (remove "easy reference"), and cross-reference
the corresponding section on the docker CLI page.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
golden.AssertBytes prints the failure as a bytes-array, which makes
it not human-readable; let's compare strings instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Laura Brehm
Sebastiaan van Stijn
Sebastiaan van Stijn
Bjorn Neergaard
Paweł Gronowski