I was experimenting with images with lots of layers (> 200) and
this invocation was incorrectly adding the entire response
into what was intended as the metadata plane.
`GetManifest` and `GetConfig` (even those are relatively small)
still always return their data over a pipe, same as blobs.
Add a new `GetLayerInfoPiped` that does the same so we
can easily get this information for images with a lot of layers.
Signed-off-by: Colin Walters <walters@verbum.org>
In PR review for a different issue, the question of what happens
if we hit overflow for the imageid serial was hit. This feels
pretty unlikely; if I did the math right, it'd require opening
an average of 136 images per second to overflow it in a year.
Nevertheless, in practice what we're sending on the wire is just a JSON
number, and if we extend this to the "max safe JSON number" of 2^53,
it'd take 285,616,414 images per second to overflow in a year, going
from implausible to probably impossible.
With a bit more work of course, we could make this a sparse mapping
and reuse freed numbers, but eh.
Signed-off-by: Colin Walters <walters@verbum.org>
gopkg.in/check.v1 hasn't had any commit since Nov 2020.
That's not a immediate issue for a test-only dependency, but
because it hides access to the standard library *testing.T,
eventually it will become limiting.
Also, using the same framework for unit and integration tests
seems practical.
This is mostly a batch copy&paste job, with a fairly high risk
of unexpected breakage.
Also, I didn't take much time at all to carefully choose between
assert.* and require.*; we can tune that as failures show up.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In some code I'm writing I want to be able to cleanly test if an
image exists, as distinguished from other errors like authentication
problems, network flakes etc.
As best I can tell, the containers/image abstraction doesn't
offer a clean way to do this.
For now, I chose the route of adding the ugly string error matching
here for the two cases I care about (docker v2s2 registry and oci
directories), so my Rust code can operate in terms of clean
`Option<Image>`.
Signed-off-by: Colin Walters <walters@verbum.org>
Mostly just name changes that should not change behavior, apart
from ioutil.ReadDir -> os.ReadDir avoiding per-item lstat(2) in
one case.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... as found by (golangci-lint run).
Note: this does not add (golangci-lint run) to the Makefile
to ensure the coding standard.
(BTW golangci-lint currently fails on structcheck, which doesn't
handle embedded structs, and that's a years-long known unfixed
limitation.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
> receiver name should be a reflection of its identity; don't use generic names such as "this" or "self" (ST1006)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Sadly...I swear I had tested this at one point, but it was
*definitely* not the intention that we just return the container
runtime configuration.
I need a method to return the full image configuration. At some point
I must have accidentally added a redundant `.Config`.
This whole new method `GetFullConfig` is like `GetConfig` but
returns the whole image configuration. A specific motivation
here is that it's only in the image configuration that we can
stick arbitrary metadata (labels) that will survive a round trip through
docker schema v2.
To fix compilation on MacOS.
I think actually we want to use this pervasively in our tests
on Linux; it doesn't really matter when run inside a transient
container, but `PDEATHSIG` is useful for persistent containers (e.g.)
toolbox and when running outside of a pid namespace, e.g. on a host
system shell directly or in systemd.
Signed-off-by: Colin Walters <walters@verbum.org>
We need to support manifest lists. I'm not sure how I missed this
originally. At least now we have integration tests that cover this.
The issue here is fairly subtle - the way c/image works right now,
`image.FromUnparsedImage` does pick a matching image from a list
by default. But it also overrides `GetManifest()` to return the
original manifest list, which defeats our goal here.
Handle this by adding explicit manifest list support code. We'll
want this anyways for future support for `GetRawManifest` or so
which exposes OCI manifest lists to the client.
Signed-off-by: Colin Walters <walters@verbum.org>
I debated adding "reverse dependency testing" using
https://crates.io/crates/containers-image-proxy
but I think it's easier to reuse the test infrastructure here.
This also starts fleshing out a Go client for the proxy (not
that this is going to be something most Go projects would want
versus vendoring c/image...but hey, maybe it'll be useful).
Now what I hit in trying to use the main test images is currently
the proxy fails on manifest lists, so I'll need to fix that.
Signed-off-by: Colin Walters <walters@verbum.org>
