Images loaded into Docker's containerd image store are identified by
their manifest or index digest, while the legacy graphdriver store uses
the config digest.
buildx prefers containerimage.config.digest when the Moby exporter
returns both digests.
Some exporter responses still produce a usable iidfile, but affected
builds, such as those with attestations disabled, write a config digest
that Docker image commands cannot resolve.
Expose the Docker driver's image-store mode as a feature and set
prefer-image-digest for containerd-backed Moby exports.
Signed-off-by: Paweł Gronowski <git@grono.dev>
Properly map the source paths from the metadata in the solve to the
client side paths. The source path returns is relative to the context
that gets uploaded which is usually a subdirectory. The original code
noticed this when mapping the paths but made the invalid assumption that
the dockerfile would always be in the context path so it combined the
dockerfile name with the context path.
It is possible for the dockerfile to be in a subdirectory of the
context. In which case, we computed the paths incorrectly.
This modifies DAP to instead use the `DockerfileMappingDst` and
`DockerfileMappingSrc` which are special included variables to the
inputs that get filled in during the build for the purpose of mapping
the source path to the client side path.
Tests have also been added for this functionality to ensure it doesn't
break again. This should work with both absolute and relative paths
although absolute paths should probably be preferred for usage just
because they're less likely to result in weird things happening.
The sources are also normalized to always convert the source filenames
to absolute paths and DAP itself will accept relative paths but will
only ever communicate in absolute paths. When you set a breakpoint, it
will convert it to an absolute path and reference it in that way rather
than a relative path.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Prior to this change, the following command emits the wrong image ID when buildx
uses the "docker-container" driver and Docker is configured with the
containerd-snapshotter.
$ docker buildx build --load --iidfile=img.txt
$ docker run --rm "$(cat img.txt)" echo hello
docker: Error response from daemon: No such image: sha256:4ac37e81e00f242010e42f3251094e47de6100e01d25e9bd0feac6b8906976df.
See 'docker run --help'.
The problem is that buildx is outputing the incorrect image ID in this scenario
(it's outputing the container image config digest, instead of the container
image digest used by the containerd-snapshotter).
This commit fixes this. See https://github.com/moby/moby/issues/45458.
Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>
CrazyMax