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>
Add the ability to use an on-disk trust store to verify signatures. Also allow the user to trust any known fingerprint instead of having to specify one.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
... mostly so that I get practice and remember this exists in the future.
(This saves one allocation & copy when the target implements
io.StringWriter. And that makes absolutely no relevant difference
on this path.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
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>
- It's unclear why it exists in the first place
- Looking at callers of imagesToCopyFromRepo, the only caller of this:
either the input is a single repo, in which case the failure to
list tags clearly results in a no-op and a "No images to sync" fatal
failure ...
- ... or the input is YAML, and in that case the caller is already
skipping the repo on a failure.
Either way, it's unclear why we would have a special "Registry disallows
tag retrieval" error special case instead of the generic text.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
They were useful before assertSkopeoSucceeds/assertSkopeoFails,
when they were used multiple times. Now, they don't
make the code any shorter.
Should not change (test) behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
We expect schema1 images to work. Also, docker/distribution
doesn't provide useful errors for rejected schema1 images
( https://github.com/distribution/distribution/issues/2925 ),
which makes it impractical for Skopeo to automatically convert
schema1 to schema2.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The k8s.gcr.io/coredns/coredns repo now contains an OCI
artifact, which we can't copy; so, use a different
repo to test syncing.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
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>
This enables pushing to registries where the push and pull uris may be
different, for example where pushed images are mirrored to a read only
replica for distribution.
Closes#1588
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
This saves us at least 2 lines (error check, and cleanup) on every
instance, or in some cases adds cleanup that we forgot.
This is inspired by, but not directly related to, Go 1.15's addition of
Testing.T.TempDir.
NOTE: This might significantly increase the tests' disk space requirements;
AFAICS the temporary directories are only cleaned up when a whole "suite
finishes running.
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.
The new --multi-arch option allows the user to select between copying the
image associated with the system platform, all images in the index, or
just the index itself without attempting to copy the images.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
This test was incorrectly assuming that nothing would be made on disk,
but it was putting files into the source directory.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
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>