Anyone running (vndr) currently ends up with failing tests in OCI schema
validation because gojsonschema has fixed its "$ref" interpretation, exposing
inconsistent URI usage inside image-spec/schema.
So, this runs (vndr), and uses mtrmac/image-spec:id-based-loader
( https://github.com/opencontainers/image-spec/pull/739 ) to make the tests pass
again. As soon as that PR is merged we should revert to using the upstream
image-spec repo again.
PR #440 reverted the vendor.conf edits of #426. This passed CI
because the corresponding vendor/* subpackages were not modified.
Restore the vendor.conf changes, and re-run full (vndr) to ensure
the two are consistent again.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
containers/storage got new dependencies, so we will need to re-vendor
eventually anyway, and having this separate from other major work is
cleaner.
But the primary goal of this commit is to see whether it makes skopeo
buildable on OS X.
Primarily vendor after merging mtrmac/image:openpgp.
Then update for the SigningMechanism API change.
Also skip signing tests if the GPG mechanism does not support signing.
Also abort some of the tests early instead of trying to use invalid (or
nil) values.
The current master of image-tools does not build with Go 1.6, so keep
using an older release.
Also requires adding a few more dependencies of our updated
dependencies.
vndr is almost exactly the same as our old good hack/vendor.sh. Except
it's cleaner and it allows to re-vendor just one dependency if needed
(which we do a lot for containers/image).
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Note that this assumes that both (docker login) and (oc login) has
happened, the credentials can be read from the usual config files,
and that the default OpenShift instance should be used.
This includes copy&pasted/modified/simplified code from OpenShift
and Kubernetes, primarily for config file parsing and setting up
TLS and HTTP authentication.
This is much smaller than linking to the upstream OpenShift client
libraries, which via various abstractions and registration drag in much
(dozens of megabytes) more code.
The primary loss from this simplification is automatic conversions
between various versions of the API objects, both for the REST API and
for local configuration storage.
This does not contain downloading/uploading signatures, which depends on
server-side support.
