In golang when copy a slice, if the slice is initialized with a
desired length, then appending to it will cause the size double.
Signed-off-by: bin liu <liubin0329@gmail.com>
Add a new config as sandbox controller mod, which can be either
"podsandbox" or "shim". If empty, set it to default "podsandbox"
when CRI plugin inits.
Signed-off-by: Zhang Tianyang <burning9699@gmail.com>
Both of these were deprecated in 55f675811a,
but the format of the GoDoc comments didn't follow the correct format, which
caused them not being picked up by tools as "deprecated".
This patch updates uses in the codebase to use the alternatives.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This updates the test to:
- Use correctly formatted values for RequiredPlugins and DisabledPlugins (values
are expected to have a `io.containerd.` prefix). While not needed for the test
to pass (no validation is performed), it's good to have these values in the
correct format (in case we want to add validation at this stage).
- Set a `Version` for both (as version 1 / no version was deprecated)
The `Version` field in this test was used to verify the "integer override"
behavior; setting "Version: 2" for both would no longer cover that case. As there
are only 2 integer fields in the config (Version and OOMScore) and OOMScore was
already used in the test, I added separate test-cases for that.
Looking at the test, we should consider what we want the behaviour to be if the
override file does not specify a version (implicitly: version 1), or if the version
is different from the original one; do we want mergeConfig() to produce an error
when merging a v2 config with a v1 config (or v3 with v2)?
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>
