Use latest Go minor release. Note: this release included fixes for
several CVEs, but they do not impact Compose.
Small errors have been fixed to keep the linter happy.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Without this I get an exception when building multiple images in a
compose run.
```
fatal error: concurrent map writes
goroutine 16 [running]:
github.com/docker/compose/v2/pkg/compose.(*composeService).build.func1({0x2cba4e0, 0xc00019b2c0}, {0xc000233150?, 0xd?})
github.com/docker/compose/v2/pkg/compose/build.go:95 +0x652
github.com/docker/compose/v2/pkg/compose.(*graphTraversal).run.func1()
github.com/docker/compose/v2/pkg/compose/dependencies.go:127 +0x63
golang.org/x/sync/errgroup.(*Group).Go.func1()
golang.org/x/sync@v0.1.0/errgroup/errgroup.go:75 +0x64
created by golang.org/x/sync/errgroup.(*Group).Go
golang.org/x/sync@v0.1.0/errgroup/errgroup.go:72 +0xa5
...
```
I'm not sure why the map is currently shared, but with this patch
applied my docker-compose build run works.
Signed-off-by: Edward Muller <emuller@fastly.com>
The scan tip has been shown for two years, and most users will know
about it by now. Presenting the message also involved checking if the
plugin was installed, and wether or not the message was shown before,
which also caused some overhead, so cleaning up the output a bit.
The corresponding DOCKER_SCAN_SUGGEST environment-variable is also
removed with this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When running `compose down`, the `--rmi` flag can be passed,
which currently supports two values:
* `local`: remove any _implicitly-named_ images that Compose
built
* `all` : remove any named images (locally-built or fetched
from a remote repo)
Removing images in the `local` case can be problematic, as it's
historically been done via a fair amount of inference over the
Compose model. Additionally, when using the "project-model"
(by passing `--project-name` instead of using a Compose file),
we're even more limited: if no containers for the project are
running, there's nothing to derive state from to perform the
inference on.
As a first pass, we started labeling _containers_ with the name
of the locally-built image associated with it (if any) in #9715.
Unfortunately, this still suffers from the aforementioned problems
around using actual state (i.e. the containers might no longer
exist) and meant that when operating in file mode (the default),
things did not behave as expected: the label is not available
in the project since it only exists at runtime.
Now, with these changes, Compose will label any images it builds
with project metadata. Upon cleanup during `down`, the engine
image API is queried for related images and matched up with the
services for the project. As a fallback for images built with
prior versions of Compose, the previous approach is still taken.
See also:
* https://github.com/docker/compose/issues/9655
* https://github.com/docker/compose/pull/9715
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
support DOCKER_DEFAULT_PLATFORM when 'compose up --build'
add tests to check behaviour when DOCKER_DEFAULT_PLATFORM is defined
Signed-off-by: Guillaume Lours <705411+glours@users.noreply.github.com>
When using the "classic" (non-BuildKit) builder, ensure that
services are iterated in dependency order for a build so that
it's possible to guarantee the presence of a base image that's
been added as a dependency with `depends_on`. This is a very
common pattern when using base images with Compose.
A fix for BuildKit is blocked currently until we can rely on a
newer version of the engine (see docker/compose#9324)[^1].
[^1]: https://github.com/docker/compose/issues/9232#issuecomment-1060389808
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
