Convert usages of `github.com/docker/docker/pkg/idtools` to
`github.com/moby/sys/user` in order to break the dependency between
buildkit and docker.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Support additional request header fields for HTTP sources, "Accept" and
"User-Agent" as a start.
The "Accept" header is required in some cases and some servers may vary
the response body based on the header value.
The "User-Agent" header may be useful in custom frontends and
potentially other cases.
- llb: Add `llb.Header` and `HTTPInfo.Header` to allow `client/llb`
users to set these header fields on HTTP sources. The argument to
`llb.Header` is a struct to effectively limit header fields to a
subset.
- llb: Define and flag new `source.http.header` capability when
`llb.Header` is used.
- solver: Define new `http.header.` source attribute prefix. Giving
each header field its own attribute (opposed to JSON encoding the
header struct) will allow source policy to make assertions on
individual header fields.
- source/http: Parse `http.header.` attributes into a sorted slice and
include them in cache key digest.
- source/http: Set request headers accordingly.
Signed-off-by: Dan Duvall <dduvall@wikimedia.org>
Support authentication for HTTP sources.
- llb: Define general `llb.AuthOption` interface composed of
`HTTPOption` and `GitOption`.
- llb: Refactor `llb.AuthHeaderSecret` to return an `llb.AuthOption` so
it may be used with both `llb.Git` and `llb.HTTP`.
- llb: Define `HTTPInfo.AuthHeaderSecret`.
- llb: Define and flag new `source.http.auth` capability when
`HTTPInfo.AuthHeaderSecret` is set.
- solver: Define new `http.auth` source attribute.
- source/http: If an `http.auth` attribute is specified, resolve a
secret named by its value and set the "Authorization" request header.
Signed-off-by: Dan Duvall <dduvall@wikimedia.org>
Currently the lookup from previous local etags was based on
filename. This leads to possibility where (misbehaving) server
may reuse the same eTag for different URLs. While using only
the filename might theoretically create more cache matches when
the same file is used via multiple URLs, I think was accidental
mistake and not intentional.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
There is a possibility to get a digest mismatch error
if the metadata for previous download does not point to
a valid reference anymore.
To mitigate this, check that ref that etag points to
is still valid before using it.
Additionally `.cacheKey` property was not previously
set in the cases where old reference was reused. This
caused a case where even if the download needed to be
performed again, it always failed validation, even if
the digest had not actually changed since previous download.
There is still a small possibility that gc/prune request
will delete the downloaded record in between cachemap and
exec call and that the contents changes in the server
at that exact time. To fix that case we would need to
modify cachemap so that it can keep hold of references
until build is complete.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
On a build with no-cache, cache mounts were not pruned correctly
if the mount was on top of another ref. This also appeared in
Dockerfile when mode/uid/gid was set because implicit parent
ref is created in these cases in order to change the permissions
of a subdir that is used as a cache mount base.
Because it is not possible to know ahead of time what ref
will become the parent of cache mount during build, all cache
mounts matching the ID that have a parent will be pruned.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Sources are a pretty neat extension point, except there are a few code
paths that hard-code against each type. This moves code around and
adjusts interfaces so that Source implementations are self-contained and
merely need to be registered with the source.Manager.
Signed-off-by: Alex Suraci <suraci.alex@gmail.com>
