fix: swapping from quay to in memory test registry - #2228
Open
tommyd450 wants to merge 10 commits into
Open
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2228 +/- ##
==========================================
+ Coverage 59.56% 59.78% +0.22%
==========================================
Files 291 292 +1
Lines 16384 16447 +63
==========================================
+ Hits 9759 9833 +74
+ Misses 5638 5619 -19
- Partials 987 995 +8
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
osmman
reviewed
Aug 18, 2026
| ) | ||
|
|
||
| const ( | ||
| registryImage = "docker.io/library/registry:2" |
Collaborator
There was a problem hiding this comment.
Have we got configured mirror for not pulling directly from docker.io? If not than our job will be unstable due rate limiting from docker registry.
Collaborator
There was a problem hiding this comment.
We are using mirror.gcr.io in other automations
Contributor
Author
There was a problem hiding this comment.
Nope, will look into it, was hoping to move this along on friday to remove secret config for running e2e tests on cluster.
Collaborator
There was a problem hiding this comment.
you can cahnge it to mirror.gcr.io/library/registry:2
The in-memory test registry serves plain HTTP (no TLS). The --allow-insecure-registry flag only skips TLS certificate verification but still uses HTTPS, causing "http: server gave HTTP response to HTTPS client" errors when cosign runs inside the cluster. Adding --allow-http-registry tells cosign to use plain HTTP connections. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace in-cluster Kubernetes registry deployment with pure in-memory implementation using go-containerregistry's built-in registry handler. Eliminates Deployment/Service/port-forwarding overhead, enabling faster test startup while maintaining full OCI compatibility. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Instead of running an in-memory registry on the test host, deploy the registry as a pod within the Kubernetes cluster. This approach: - Works consistently across all Kubernetes environments (Kind, OpenShift, etc) - Uses standard Kubernetes Service DNS for pod-to-pod communication - No need for host.docker.internal or environment-specific configuration - Uses official 'registry:2.8' container image for production-like behavior The registry is deployed in the test namespace with: - A Deployment running the registry container - A Service exposing the registry on port 5000 - ClusterIP service DNS: test-registry.<namespace>.svc:5000 Images are pushed locally via port-forwarding during test setup, then cosign and other pods access the registry via the service DNS name from within the cluster. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
The test registry now runs as a pod in the cluster, but tests still need to push images from the host machine. Add port-forwarding coordination to make this work smoothly. This maintains support for both: - Pushing images from the test host (via localhost:5000) - Accessing the registry from cluster pods (via service DNS) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Implements automatic detection and optimal strategy selection: **Outside Cluster (GitHub Actions + Kind):** - Runs in-memory registry on the host (localhost:5000) - Discovers Docker gateway IP for pod access (172.17.0.1, host.docker.internal, etc) - Tests push images locally, pods access via gateway IP - No port-forwarding or extra setup needed **Inside Cluster (OpenShift/Kubernetes):** - Detects presence via KUBERNETES_SERVICE_HOST env var - Deploys registry as a Kubernetes pod with Service - Pods access via service DNS (test-registry.namespace.svc:5000) - Works across all Kubernetes environments The registry automatically chooses the best approach for each environment, with zero configuration needed. Handles both GitHub Actions (Kind) and production Kubernetes/OpenShift scenarios seamlessly. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
When running in OpenShift/Kubernetes (inside a pod), tests get a controller-runtime client.Client, not a kubernetes.Interface. Support both client types so registry deployment works in both GitHub Actions (Kind) and OpenShift pipelines scenarios. This ensures the in-cluster registry deployment actually creates resources when running in the pipelines repo's OpenShift environment. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.