The behavior of this function is quite counter-intuitive, as it preserves
the delimiter in the result, and its use for external consumers would be
very limited.
Spec.Digest no longer uses this function, and it appears that BuildKit is
currently the only (publicly visible) external consumer of it.
This patch deprecates the function.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fec33aa735)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Inline the relevant code from SplitObject, as we're only interested
in the digest portion.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a5fce38f31)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The behavior of this function is quite counter-intuitive, as it preserves
the delimiter in the result. This function should probably have been an
internal function, as its use for external consumers would be very limited,
but let's at least document the (surprising) behavior for those that are
considering to use it.
It appears that BuildKit is currently the only (publicly visible) external
consumer of this function; I am planning to inline its functionality in
Spec.Digest() and to deprecate this function so that it can be removed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 42145950bb)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were straight concatenations of strings; reduce some allocations by
removing fmt.Sprintf for this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 799bca97f2)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function is deprecated in distribution/reference, and removed
in distribution/reference v0.6; reference.Domain or reference.Path
should be used instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The reference/docker package was a fork of github.com/distribution/distribution,
which could not easily be used as a direct dependency, as it brought many other
dependencies with it.
The "reference' package has now moved to a separate repository, which means
we can replace the local fork, and use the upstream implementation again.
The new module was extracted from the distribution repository at commit:
https://github.com/distribution/distribution/commit/b9b19409cf458dcb9e1253ff44ba75bd0620faa6
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 4923470902)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Current registry reference use a subset of dns and IPv4 addresses to
represent a registry domain.
Since registries are mostly compatible with rfc3986, that defines the
URI generic syntax, this adds support for IPv6 enclosed in squared
brackets based on the mentioned rfc.
The regexp is only expanded to match on IPv6 addreses enclosed between
square brackets, considering only regular IPv6 addresses represented
as compressed or uncompressed, excluding special IPv6 address
representations.
Signed-off-by: Antonio Ojea <antonio.ojea.garcia@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previous implementation was doing a lot of string -> regexp -> string
conversions
Signed-off-by: Paul Cacheux <paul.cacheux@datadoghq.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add context to comment to explain the repo name regex in addition to describing it.
Signed-off-by: David Warshaw <david.warshaw@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Go 1.13 and up enforce import paths to be versioned if a project
contains a go.mod and has released v2 or up.
The current v2.x branches (and releases) do not yet have a go.mod,
and therefore are still allowed to be imported with a non-versioned
import path (go modules add a `+incompatible` annotation in that case).
However, now that this project has a `go.mod` file, incompatible
import paths will not be accepted by go modules, and attempting
to use code from this repository will fail.
This patch uses `v3` for the import-paths (not `v2`), because changing
import paths itself is a breaking change, which means that the
next release should increment the "major" version to comply with
SemVer (as go modules dictate).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package was forked from the https://github.com/distribution/distribution
repository in commit 901bcb2231, but that commit
did a plain copy of the code (minus tests), and rewrote the code to be in a
single file. The same commit also removed some deprecated code for handling
"shortid" references (ParseAnyReferenceWithSet() function), in order to avoid
the "digestset" dependency from the distribution repo.
At the time, containerd used the distribution/distribution package from this
commit: https://github.com/distribution/distribution/commit/0d3efadf0154c2b8a4e7b6621fff9809655cc580
Since the code was forked, both containerd and distribution have received
improvements and fixes, so unfortunately, the code started to diverge.
I'm planning to reconcile the packages (potentially by using a shared module),
and this is the first commit to assist with that.
This patch restructures the reference/docker package to split the code into the
same files as are used in the upstream distribution/distribution repository.
This makes it easier to compare the implementations in both repositories (to
allow synchronizing changes).
No changes are applied yet, other than splitting the code (follow-up commits
will take care of syncing changes across).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
An image ref must be a scheme-less URI. A reference with scheme (such
as `http://`) must return ErrInvalid.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
Split resolver to only return a name with separate methods
for getting a fetcher and pusher. Add implementation for
push.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
After receiving feedback during containerd summit walk through of the
pull POC, we found that the resolution flow for names was out of place.
We could see this present in awkward places where we were trying to
re-resolve whether something was a digest or a tag and extra retries to
various endpoints.
By centering this problem around, "what do we write in the metadata
store?", the following interface comes about:
```
Resolve(ctx context.Context, ref string) (name string, desc ocispec.Descriptor, fetcher Fetcher, err error)
```
The above takes an "opaque" reference (we'll get to this later) and
returns the canonical name for the object, a content description of the
object and a `Fetcher` that can be used to retrieve the object and its
child resources. We can write `name` into the metadata store, pointing
at the descriptor. Descisions about discovery, trust, provenance,
distribution are completely abstracted away from the pulling code.
A first response to such a monstrosity is "that is a lot of return
arguments". When we look at the actual, we can see that in practice, the
usage pattern works well, albeit we don't quite demonstrate the utility
of `name`, which will be more apparent later. Designs that allowed
separate resolution of the `Fetcher` and the return of a collected
object were considered. Let's give this a chance before we go
refactoring this further.
With this change, we introduce a reference package with helps for
remotes to decompose "docker-esque" references into consituent
components, without arbitrarily enforcing those opinions on the backend.
Utlimately, the name and the reference used to qualify that name are
completely opaque to containerd. Obviously, implementors will need to
show some candor in following some conventions, but the possibilities
are fairly wide. Structurally, we still maintain the concept of the
locator and object but the interpretation is up to the resolver.
For the most part, the `dist` tool operates exactly the same, except
objects can be fetched with a reference:
```
dist fetch docker.io/library/redis:latest
```
The above should work well with a running containerd instance. I
recommend giving this a try with `fetch-object`, as well. With
`fetch-object`, it is easy for one to better understand the intricacies
of the OCI/Docker image formats.
Ultimately, this serves the main purpose of the elusive "metadata
store".
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Sebastiaan van Stijn