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>
When server returns a weak etag, the prefix can
cause a mismatch on direct comparison with old value.
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>
Before this, there was a bug triggered under the following conditions:
1. An overlay snapshotter was being used, which caused the optimization
of preparing a new snapshot off of the base layers to be triggered
2. The base layers contained a directory that had contents
3. One subsequent layer deleted that directory w/out recreating it
4. A later layer recreated the directory
In this case, what happened was a whiteout device would be created as
part of 3 above but then in step 4 the whiteout device would be removed
and replaced with a plain directory. The problem is that such a
directory doesn't block out the files from step 2 and it doesn't know
about them because they are in a lowerdir (not the upperdir being
applied to).
The simplest fix, which this commit implements, is to just set the
directory created in step 4 as opaque, which enables the correct
behavior of blocking out files below it.
This was missed in test coverage before because tests for opaque
handling always combined 3+4 into one layer, whereas the bug requires
they be separate layers. A new integration test has been added to cover
this case.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
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>
The merge diff tests were using some common LLB state objects across
multiple test cases, which each have their own buildkit client and ran
in parallel. The LLB client library does not appear to currently work
with such use cases where LLB states are shared, with errors about
concurrent map writes to marshal state constraints occasionally being
hit during test runs.
Until that issue is addressed (or it's made explicit that the LLB client
library is not expected to work in such a way), this works around the
problem by not sharing states and instead using common funcs that return
distinct state instances.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
This fixes an issue where if a vertex rapidly had progress updates (such
as the case where CacheMap runs in succession for multiple indexes),
then progress updates were all using the same ID and could incorrectly
override one another, resulting in missing vertex updates.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
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>
Now, when a merge or diff ref is unlazied, the progress will show up
under the vertex for the merge/diff ref. Additionally, any ancestors of
the op that also need to be unlazied as part of unlazying the merge/diff
will show status updates under its vertex in the progress.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>