… to 25.0.0-rc.2+incompatible (#11348)

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ble to 25.0.0-rc.2+incompatible (#11349)

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

….12 (#11347)

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>

The changes in
dcbf005
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: moby/moby#47073) so we reverted the
process group id changes and ended at a temporary solution in
docker/cli#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>

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>

Bumps [github.com/docker/cli](https://github.com/docker/cli) from 25.0.0-rc.2+incompatible to 25.0.0-rc.3+incompatible.
- [Commits](docker/cli@v25.0.0-rc.2...v25.0.0-rc.3)

---
updated-dependencies:
- dependency-name: github.com/docker/cli
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

signals/utils: always handle received signals

Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>

remove watch subcommand from the alpha command

…m/docker/cli-25.0.0-rc.3incompatible

build(deps): bump github.com/docker/cli from 25.0.0-rc.2+incompatible to 25.0.0-rc.3+incompatible

Bumps [github.com/docker/docker](https://github.com/docker/docker) from 25.0.0-rc.2+incompatible to 25.0.0-rc.3+incompatible.
- [Release notes](https://github.com/docker/docker/releases)
- [Commits](moby/moby@v25.0.0-rc.2...v25.0.0-rc.3)

---
updated-dependencies:
- dependency-name: github.com/docker/docker
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

…m/docker/docker-25.0.0-rc.3incompatible

build(deps): bump github.com/docker/docker from 25.0.0-rc.2+incompatible to 25.0.0-rc.3+incompatible

Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>

bump version of compose-go to v2.0.0-rc.1