Docker Image manifest v2, schema version 1 is deprecated since 2015, when
manifest v2, schema version 2 was introduced (2e3f4934a7).
Users should no longer use this specification other than for backward
compatibility.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This makes them easier to find between the non-exported ones, and puts
them as separate sections in the generated docs. While updating, also
extended documentation for some to be more descriptive.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Localhost is treated special when parsing references, and always considered
to be a domain, despite not having a "." nor a ":port". Adding a const for
this, to allow documenting this special case (making it more visible).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This pattern was used in two places, so adding an intermediate variable allows
documenting its purpose. The "remote-name" grammer (which is interchangably
used with "path") also seemed to be missing from the grammar, so adding it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `domain` variable didn't make it clear that this could include port-numbers
as well, so renaming it makes that more visible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The remaining uses of "expression()" were quite trivial; probably goes without
saying, but just using string-concatenating for these is more performant as well,
and removing the extra abstraction may make it easier to read;
pkg: github.com/distribution/distribution/v3/reference
BenchmarkExpression
BenchmarkExpression-10 27260877 43.10 ns/op 24 B/op 1 allocs/op
BenchmarkConcat
BenchmarkConcat-10 1000000000 0.3154 ns/op 0 B/op 0 allocs/op
PASS
ok github.com/distribution/distribution/v3/reference 1.762s
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With the exception of ".", none of the literals used required escaping, which made
the function rather redundant (and the extra abstraction made it harder to read).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
NameRegexp does not have capturing groups, so updating the documentation
to reflect that.
To verify if this was an unintentional regression, I looked up the commit
that introduced this regex (31a448a628), and
it looks like it never had capturing groups, so this was just a mistake in
the docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch:
- makes regexp strings that are constant a const
- moves some variables closer to where they're used
- removes some intermediate vars
- un-wraps some lines; they're lengthy, but probably more readable than having
them wrapped over multiple lines.
- touches-up some docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Not all tests have been rewritten to use sub-tests; for those
I enabled t.Parallel() for the parent test only.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`registry/storage/driver/inmemory/driver_test.go` times out after ~10min. The slow test is `testsuites.go:TestWriteReadLargeStreams()` which writes a 5GB file.
Root cause is inefficient slice reallocation algorithm. The slice holding file bytes grows only 32K on each allocation. To fix it, this PR grows slice exponentially.
Signed-off-by: Wei Meng <wemeng@microsoft.com>
Go 1.18 and up now provides a strings.Cut() which is better suited for
splitting key/value pairs (and similar constructs), and performs better:
```go
func BenchmarkSplit(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_ = strings.SplitN(s, "=", 2)[0]
}
}
}
func BenchmarkCut(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_, _, _ = strings.Cut(s, "=")
}
}
}
```
BenchmarkSplit
BenchmarkSplit-10 8244206 128.0 ns/op 128 B/op 4 allocs/op
BenchmarkCut
BenchmarkCut-10 54411998 21.80 ns/op 0 B/op 0 allocs/op
While looking at occurrences of `strings.Split()`, I also updated some for alternatives,
or added some constraints;
- for cases where an specific number of items is expected, I used `strings.SplitN()`
with a suitable limit. This prevents (theoretical) unlimited splits.
- in some cases it we were using `strings.Split()`, but _actually_ were trying to match
a prefix; for those I replaced the code to just match (and/or strip) the prefix.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Embed the interface that we're mocking; calling any of it's methods
that are not implemented will panic, so should give the same result
as before.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use strings.HasPrefix() to check for the prefix we're interested in instead
of doing a strings.Split() without limits. This makes the code both easier
to read, and prevents potential situations where we end up with a long slice.
- use consts for defaults; these should never be modified, so better to use
consts for them to indicate they're fixed values.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package was only used for the deprecated "shortid" syntax. Now that
support for this syntax was removed, we can also remove this package.
This patch deprecates and removes the package, adding temporary aliases pointing
to the new location to ease migration from docker/distribution to the new
distribution/distribution/v3. We should remove those aliases in a future update.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This upstreams `Sort()` as originally implemented in containerd in
https://github.com/containerd/containerd/0886ceaea2470edc7339dfc5ebe0e3257ae84d06
From that commit:
> Fix reference ordering in CRI image store
>
> Currently image references end up being stored in a
> random order due to the way maps are iterated through
> in Go. This leads to inconsistent identifiers being
> resolved when a single reference is needed to identify
> an image and the ordering of the references is used for
> the selection.
>
> Sort references in a consistent and ranked manner,
> from higher information formats to lower.
>
> Note: A `name + tag` reference is considered higher
> information than a `name + digest` reference since a
> registry may be used to resolve the digest from a
> `name + tag` reference.
Co-Authored-by: Derek McGowan <derek@mcg.dev>
Co-Authored-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Milos Gajdos
Sebastiaan van Stijn
CrazyMax
AdamKorcz
Wei Meng
Wang Yan
Derek McGowan