It appears that multiple parallel builds suffer some cross talk between their
mount/snapshots e.g. this new case currently fails because iterations see files
in `/src/` which correspond to other iterations (i.e. iteration 1 might see a
file called "test2.txt"). The `ls -i` and `stat` output also confirms that
where tests see the same filename they are also apparently seeing the same
inode.
Note that each solve uses a `SolverOpt.SharedKey` of the (unique) source
directory so there should be no clashes. Use of `llb.sharedKeyHint()` is
avoided since using a unique one of these hides the issue (AIUI uniqueness of
`sharedKeyHint` is only required with a session, not between them).
The shell fragment within the test is a bit crazy, it tries to output as much
info about what it saw vs what was expected to aid debugging.
I have also been seeing cases in my own code where `cacheContext.checksum`
fails the `not found` test at the top, which seems like either the wrong thing
is mounted or it has gone away or otherwise been mutated unexpectedly. I had
been hoping that this test case would also reproduce this, but so far it has
not.
Signed-off-by: Ian Campbell <ijc@docker.com>
Adds image and oci exporter option "oci-mediatypes"
Ensures that the images created in the content store
have the correct type which matches the manifest.
Sets the correct media type on the descriptor in push from
reading the type specified in the manifest.
Removes use of distribution manifest packages.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
This allows two things:
- The caller to set a shorter timeout than previously hardcoded 30s. In
`buildctl` reduce the timeout to 5s. Since the existing timeout has gone
callers will need to arrange to pass one themselves.
- The caller can arrange for the context to be cancelled for other reasons, use
this in `buildctl` to plumb through the Ctrl-C handling, meaning that
`buildctl` now exits almost immediately on Ctrl-C instead of after several
seconds.
Signed-off-by: Ian Campbell <ijc@docker.com>
e.g. with busybox image:
OCI runtime create failed: container_linux.go:348:
starting container process caused "process_linux.go:402:
container init caused \"rootfs_linux.go:58:
mounting \\\"proc\\\" to rootfs \\\"/.../rootfs\\\" at \\\"/proc\\\"
caused \\\"mkdir /.../rootfs/proc: read-only file system\\\"\"": unknown
This is because we were setting the underlying snapshot readonly so the various
mountpoints (here /proc) cannot be created. This would not be necessary if
those mountpoints were present in images but they typically are not.
The right way to get around this (used e.g. by `ctr`) is to use a writeable
snapshot but to set root readonly in the OCI spec. In this configuration the
rootfs is writeable when mounts are processed but is then made readonly by the
runtime (runc) just before entering the user specified binary within the
container.
This involved a surprising amount of plumbing.
Use this new found ability in the dockerfile converter's `dispatchCopy`
function.
Signed-off-by: Ian Campbell <ijc@docker.com>
Otherwise the daemon panics when generating the OCI spec.
For belt and braces check in the ExecOp Run function but also when generating the spec.
Signed-off-by: Ian Campbell <ijc@docker.com>
Tonis Tiigi
Ian Campbell
Derek McGowan
Akihiro Suda
Akihiro Suda
Vincent Demeester