Add e2e tests

[BobyMCbobs]

Adds some e2e tests to target registry.k8s.io:

• Pull image pause:3.6
• Pull an image that doesn't exist
• Get https://registry.k8s.io/v2/ with redirects
• Get https://registry.k8s.io/v2/ without redirects

Related #24

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: BobyMCbobs
To complete the pull request process, please assign thockin after the PR has been reviewed.
You can assign the PR to them by writing /assign @thockin in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[BenTheElder]

I think what I'm actually looking for in #24 is mentioned by this part:

We should then make sure we have k8s e2e jobs that use registry-sandbox, and have them in a testgrid dashboard for this project.

We should have actual kubernetes e2e tests (like kubetest + gce) running in a testgrid dashboard for this project with alerting (conformance tests maybe? or just the parallel subset?) but using registry-sandbox.k8s.io as the kubernetes image registry with the latest code from this repo deployed to registry-sandbox.k8s.io (#24 (comment) => kubernetes/k8s.io#3411), so we know even the cloud run deployment etc is configured correctly, and that it works with a real client we can expect.

I think this will drive far higher confidence that we're ready to promote a change from the sandbox to production.

In #23 I think we can write something reasonable with a shell script + crane to spot check running a local registry binary and pull a known small image (pause?) through it, and add this as a make integration rule, which will give us a quicker way to test changes while developing / in presubmit, though with lower confidence. We can track crane in the hack/tools module and build and run an archeio binary locally with the make targets.

[BenTheElder]

let's move the test tool to it's own module, so we can clearly keep imports minimal in the main binary and not require downloading + installing test-only deps during building.

[BenTheElder]

(or, perhaps rework entirely 😅 #32 (review))

[BenTheElder]

we sort of have those e2e jobs today, but instead they're not in a dashboard we're tracking and they're using the production domain ahead of us rolling that out more widely, we're missing "auto deploy the latest code to registry-sandbox" and "run some realistic CI jobs against registry-sandbox".

I think for running against the deployed registry, we should skip straight to an actual cluster pulling from it, and only use containerregistry/crane as the client for local integration tests where it's not as reasonable to use a cluster / we're not covering the deployment configs anyhow.

[BenTheElder]

thanks for the PR, I've added an integration test in #47, we should setup the auto-deployed sandbox with e2e test clusters running against it in a dashboard in #24.