The existing code was spuriously failing unit tests, because it was
stripping non-permission bits off the file mode.
On examination, the behaviour was inherited from similar code in
moby/moby, which was intended to affect the resulting filemodes inside
a Linux-based container built from Windows. However, this code path does
have that effect in BuildKit as we are only calculating checksums here.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
The existing test fails because the Windows default PATH (as far as LLB
knows) is empty. See the system.DefaultPathEnv comments.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Due to use of filepath.Clean(), on Windows we end up operating on the
paths in Windows-slashed form, even if the inputs were Unix-slashed.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
These were previously failing due to use of sh.exe on Windows, and with
that fixed, have been revealed to depend on bind-mounts.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Containerd's mounter doesn't yet support bind-mounts on Windows.
BuildKit short-cuts this for read-write mounts, but not read-only
mounts.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
`go test` complains about this tree because the package ends up with no
symbols on non-Linux platforms, e.g., Windows, even though this API is
never be called on non-Linux platforms, according to the compiler.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Although we don't run any integration tests on Windows at this time,
this does mean that the SKIP_INTEGRATION_TESTS env-var works, so we can
run a wider range of non-integration tests without spurious failures.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Only a few tests are able to be run, because the integration test
support code fails to compile on Windows, taking effect before the
SKIP_INTEGRATION_TESTS env-var is handled.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
There's no Loopback CNI plugin for Windows as far as I can see, so I'm
assuming it's not needed.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
The `WithLoNetwork` and `WithConfFile` options consume the
`WithPluginDir` and `WithInterfacePrefix` settings, so they must come
first.
This fixes the issue that the provided plugin directory was not used for
the provided configuration file. This would have been more visible, but
the default `InterfacePrefix` is already "eth".
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
The Windows API is completely different, so the common code cannot
create the unique identifier, but must accept what the OS-specific code
does.
For Linux, it's a pathname. In Windows, it's a GUID string.
This pulls in direct usage of Microsoft/hcsshim, which previously was
only an indirect usage via containerd calls from, e.g., localMounter on
Windows.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>