This is just cosmetic; alighn the fields with the order in which they appear
in the struct (and JSON output).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I am looking at aligning the types defined in this repository with the
OCI image specification, and potentially exchanging local types with
those from the specification.
This patch is a stepping-stone towards that effort, but as this changes
the format of the serialized JSON, I wanted to put this up first before
proceeding with the other work in case there are concerns.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
