A panic was encountered where writes to progress status hit a nil
writer. While not easy to reproduce, this commit fixes a likely culprit.
The use of atomics in the controller was not safe against a race such as
the following:
1. One goroutine calls Start, incrementing count but not yet setting
writer.
2. A second goroutine calls Start, increments count again but sees that
count >1 and thus doesn't try to set writer.
3. The second goroutine then calls Status, assuming the writer has been
set, but the first goroutine still hasn't set the writer yet, causing
a nil pointer exception.
This commit fixes that issue by just using a mutex instead of atomics.
It also adds a nil check for the writer just to be safe against panics
due to unknown issues in the future as missing a status update is much
better than buildkitd crashing.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
When server does not return expiration time for token
default to 60s. This replaces previous solution
in error handling that broke cross-repo push.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
This reverts commit 9b7a5fc618.
This patch casues issues for cross-repo mounts
when user doesn't have credentials for source repo
and fallback needs to happen.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Foreign layers are only kept as foreign at this point if the user
requested it to be.
Since foreign layers are not meant to be pushed, automatically skip
those layers.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This just makes sure the logic for the layer conversion is all in one
place and settable by a common option.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Before this change buildkit was changing the media type for
non-distributable layers to normal layers.
It was also clearing out the urls to get those blobs.
Now the layer mediatype and URL's are preserved.
If a layer blob is seen more than once, if it has extra URL's they will
be appended to the stored value.
On export there is now a new exporter option to preserve the
non-distributable data values.
All URL's seen by buildkit will be added to the exported content.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Previously, vertexes sent to progress might have multiple intervals in
which they started+stopped, but the output only knew about the most
recent interval. Now, all the intervals are tracked and the total time
spent on each (after accounting for overlaps) is displayed. This is
implemented both for normal vertexes and progress group vertexes.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
This allows clients to specify that LLB states should be grouped in
progress output under a custom name. Status updates for all vertexes in
the group will show up under a single vertex in the output.
The intended use cases are for Dockerfile COPY's that use MergeOp as a
backend and for grouping some other internal vertexes during frontend
builds.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
compression-level option can be set on export to
define the preferred speed vs compression ratio. The
value is a number dependent on the compression algorithm.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Working with strings is error-prone because a platform
can be in multiple string forms and less flexible.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
open-telemetry/opentelemetry-specification#740 has decided to
promote different set of env for CLI propagation.
Switch to use them so we are more consistent with other
tools. Old ones should be removed in a future release.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
This breaks the giant blob that was the diffApply function into two
separate parts, a differ and an applier, which results in more modular
code that should be easier to follow and easier to make any future
updates to. For example, if we want to optimize by allowing differ and
applier to run in parallel in the future, that's straightforward now.
There are also some fixes that weren't needed for MergeOp, but will be
for DiffOp, such as correctly handling the case where a deletion is
applied that is under parent directories which don't exist yet (the
correct behavior is, surprisingly, to create the parent directories as
that is what the image import/export code ends up doing).
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
Before this change, test cases were running with an env var that forces
the overlay differ to be on even when the native snapshotter was being
used, which resulted in failures. Now, that env var is skipped when
using the native snapshotter.
Additionally, this includes a related change to skip even trying to use
the overlay differ when the native snapshotter is in use. Previously,
the blob creation code first tried to use the overlay differ and then
failed and fell back to the double-walking differ. Now, it just jumps
right to the double-walking differ when the native snapshotter is in
use.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
Using an interface instead of a func is more flexible while achieving
the same effect. It allows you to succintly define a large number of
test cases as structs, as is common in table-driven testing.
A helper func is added that converts the existing test funcs into the
interface, so the change is fairly seamless.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
This change results in the overlay differ comparing files to determine
if they are actually part of the diff. This is needed to resolve
differences between the blobs created by the overlay differ and the
double-walking differ.
Before this change, the overlay differ always just assumed that if a
file was in the upperdir it must be part of the diff and included it as
an add or a modify change. However, there are situations in which files
can appear in the upperdir without having been modified or even opened.
For example, if "foo" is a file or dir present in the lowerdirs of an
overlay mount and you run "mv foo footmp; mv footmp foo", then the
upperdir will contain foo (in addition to any files found under foo if
it's a dir). In this situation, the double-walking differ would not
include foo as part of the diff, but the overlay differ would.
This meant that the overlay differ would potentially include extra files
in each blob for such diffs relative to the double-walking differ. As of
now, while this does increase image size, it doesn't result in any
inconsistencies in terms of the contents of images because it just
results in files/dirs getting duplicated on top of their equivalents.
However, for the upcoming DiffOp support, this inconsistency could
actually result in the same operation producing mounts with different
contents depending on which differ is used. This change is therefore
necessary in order to enforce DiffOp consistency (on top of the possible
improvements to exported image size).
The main concern here is that this could undo the performance benefits
that the overlay differ was intended to fix. However, in practice the
situations where this has worse performance are quite obscure and the
benefits should still be present.
First, consider the case where foo is a directory and the user does the
equivalent of "mv foo footmp; mv footmp foo". Even before this change,
the overlay differ would see that foo is marked as opaque and thus fall
back to using the double-walking differ. So there's no performance
regression in this case as the double-walking differ does the same
file comparisons as were added in this commit.
For the case where the user shuffles a file back and forth, there will
potentially be a slow file content based comparison if the underlying
file has a truncated nanosecond timestamp (i.e. it was unpacked from a
tar file). However, the situations in which you shuffle an individual
file without changing it (or open it for writing but then write nothing)
that is large enough in size for content comparisons to be slow are
obscure. Additionally, while the content comparison may be slow, there
will be time saved during export because the file won't be included
unnecessarily in the exported blob, so it's a tradeoff rather than a
pure loss.
In situations where the user actually did change a file and it shows up
in the upperdir, it should be extremely rare that the content comparison
code path is followed. It would require that the user changed no other
metadata of the file, including size, and both mod timestamps were the
same (which could only really happen if their underlying filesystem
lacked support for nanosecond precision and they modified the file
within 1 second of its modification in the lowerdir or they manually
changed the modtime with chtimes).
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
The "defer" is bound to the original value of the ticker, and won't stop
a ticker that's created later in the function. Example:
https://play.golang.org/p/puat5JEf5Jw
Ran into this in a health checker that periodically created buildkit
clients.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
This consists of just the base MergeOp with support for merging LLB
results that include deletions using hardlinks as the efficient path
and copies as fallback.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
Erik Sipsma
Tõnis Tiigi
CrazyMax
Brian Goff
Kohei Tokunaga
Akihiro Suda
Sebastiaan van Stijn
Aaron Lehmann