Add integration coverage for imagetools create --file and verify a
descriptor read from disk resolves to the expected copied manifest.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Add integration coverage for imagetools create --append and verify the
target is rewritten as a two-platform manifest list.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Add integration coverage for imagetools create --platform on an attested
multi-platform image and verify only the matching attestation remains.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Verify copied index content keeps the same digest and descriptor metadata.
Add function comments to clarify each imagetools integration test case.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Skip the load build context step when it doesn't have an associated
source line. This caused an extra branch to be created in an otherwise
pretty straightforward dockerfile where stepping in on a copy
instruction that used the context would stay on the same line because it
"stepped into" the context loading rather than being treated the same as
step next.
This resulted in some bad and confusing ergonomics with the cursor
position that were a bit confusing and unexpected.
There might be more areas to try and prune but the most common one, a
single branch instruction that doesn't have a location, now gets skipped
which is the exact thing that was generated for loading the context.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
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>
Case insensitive filesystems can cause breakpoints to not be seen or
verified. This is particularly true on Windows where the drive letter
can also participate in the filepath.
Change the detection logic for a breakpoint to be case insensitive. At
the same time, report the name of the source as part of the breakpoint
so that the editor can be told which casing we're expecting to be used.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Fix using CopyDirContentsOnly when projecting remote named contexts so
subdir contexts keep the same root semantics as local bake runs.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Seems marshalling the typed struct causes empty fields
e.g. gcpolicy = [] that (old versions of?) BuildKit do no allow.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
This provides alternative way to set values for Bake
variables without adding them the global environment variables.
This can also be used then environment variable access
is disabled with BUILDX_BAKE_DISABLE_VARS_ENV_LOOKUP.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
When a breakpoint fails to be verified, it will switch the reason to
"failed". It starts off the reason as "pending".
The `reason` field for a breakpoint was added some time after the last
release of `go-dap` which has only been updated once in the last year so
this uses the `main` branch version which contains the field.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This adds integration tests for the `dap build` command to test various
behavior associated with the command. We start the build and the
integration test acts as a dap client to send requests and check that
the output is what we expect.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Tonis Tiigi